Undefined Behavior Optimizations in C

"Lucian Popescu" <lucic71@ctrl-c.club>
5 Jan 2023 10:05:49 +0000

          From comp.compilers

Related articles
Undefined Behavior Optimizations in C lucic71@ctrl-c.club (Lucian Popescu) (2023-01-05)
RE: Undefined Behavior Optimizations in C nuno.lopes@tecnico.ulisboa.pt (Nuno Lopes) (2023-01-05)
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-05)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-05)
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-06)
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-06)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-06)
[29 later articles]
| List of all articles for this month |

From: "Lucian Popescu" <lucic71@ctrl-c.club>
Newsgroups: comp.compilers
Date: 5 Jan 2023 10:05:49 +0000
Organization: Compilers Central
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="50451"; mail-complaints-to="abuse@iecc.com"
Keywords: semantics, optimize
Posted-Date: 05 Jan 2023 11:51:36 EST

Hi,


I'm currently working on an academic project that analyzes the speedup gain of
Undefined Behavior Optimizations in C. I argue that UB Optimizations introduce
more risks than actual speedup gains. This happens because most of the time
the compiler does not have the context to understand the intention of the
programmer in code that contains UB. For example this fast inverse square root
function [1] triggers UB at this line: i = * ( long * ) &y;. A "smart"
compiler could delete this line as an optimization because it contains UB.


Don't get me wrong, I'm not saying that the compiler should magically
understand situations where the programmer makes UB mistakes and then
repair them. What I'm saying is that the compiler should compile the code
"as is" without making smart optimization transformations that break the
intention of the programmer.


To test the theory that the UB Optimizations introduce more risks than speedup
gains, I take OpenBSD (for its focus on security and robustness) and compile
it
on one hand with UB Optimizations turned on and with UB Optimizations turned
off. If I will find out that the speedup gain is not so big (I don't know what big
means at the moment) then the UB Optimizations don't make sense in the OS.
Otherwise, it means that I was wrong, but I will still want to see what
security
risks they introduce on the respective OS setup.


My current progress is here [2]. I did not start the technical work, ATM I only
have the research proposal. I reached you to see if you have any feedback
on this proposal. Is it a manageable goal? Do you see ways in which it can
be improved? Does it suck? etc, etc.


Lucian Popescu


[1] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code
[2] https://tildegit.org/lucic71/dissertation/src/branch/master/TSW/tsw.pdf


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.