Re: Undefined Behavior Optimizations in C

gah4 <gah4@u.washington.edu>
Thu, 5 Jan 2023 16:22:07 -0800 (PST)

          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 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)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-06)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-06)
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-07)
[26 later articles]
| List of all articles for this month |

From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Thu, 5 Jan 2023 16:22:07 -0800 (PST)
Organization: Compilers Central
References: 23-01-009 23-01-011
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="36560"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize
Posted-Date: 05 Jan 2023 19:29:10 EST
In-Reply-To: 23-01-011

On Thursday, January 5, 2023 at 10:13:08 AM UTC-8, Spiros Bousbouras wrote:
> On 5 Jan 2023 10:05:49 +0000
> "Lucian Popescu" <luc...@ctrl-c.club> wrote:


> > I'm currently working on an academic project that analyzes the speedup gain of
> > Undefined Behavior Optimizations in C.
(snip)


> > To test the theory that the UB Optimizations introduce more risks than
> > speedup gains,


> Isn't this comparing apples and oranges ?


Probably.


You can quantify speed-up, but it is harder to quantify risk.


You might be able to quantify debug time, and how much longer
it takes to debug a program with such behavior.


Most important when debugging, is that you can trust the compiler to
do what you said. That they don't, has always been part of
optimization, but these UB make it worse.


> > 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.
(snip)


> I think it would make more sense to test with chess engines : prepare
> a collection of chess positions and see how many nodes per second an engine
> can calculate for a given position depending on how the engine was compiled.


Sounds good to me. Big enough, but not too big. And something that someone
always wants to be faster.


> Doing analogous experiments with graphics code or numerical analysis code
> would also be interesting. But an operating system , I don't know , it seems
> too general.


My thought would be all of SPEC, if you can avoid the funny SPEC rules on
using the numbers.


Numerical analysis code sounds interesting, as I don't know how much
the problem affects floating point code.


I haven't thought about this so recently. Do compilers give warnings
when they remove such UB code?


Post a followup to this message

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