Optimizers exploiting UB

Posted Jul 19, 2024 11:16 UTC (Fri) by farnz (subscriber, #17727)
In reply to: Optimizers exploiting UB by anton
Parent article: New features in C++26

It was not intended to be a transformation that is "only legal on the assumption that the codebase does not contain UB"; it was an example of a transform that is hopefully uncontroversial, in order to indicate just how much you're leaving on the table if you say "the code must behave exactly as written, and no optimizations are permitted in case a combination of optimizations result in UB doing something unexpected". In other words, that particular transform is an example of something that's barred if you say "use -O0" and yet that everyone reasonable agrees is one that should be permitted.

You even quoted the parts where I said that this wasn't an optimization that, on its own, depends on UB existing - I said "like … only often more complicated" to indicate that this transform is not itself controversial. I also said "transforms which are only legal in combination", because the problem is rarely transformations that rely on UB in their own right, but rather combinations of transforms where each transform is a valid optimization on its own, but the combination of 2 or more transforms (bearing in mind that even bad compilers have hundreds of optimizations they know how to perform) that is only OK in the absence of UB.

And the problem is that the resulting combinatorial explosion of possible combinations of transforms, each valid in its own right, and where the combination is itself valid in the absence of UB is a big space to search through. By defining more behaviours, you limit the allowed transformations and the allowed combinations of transforms, so that these combinations become compiler bugs, instead of bugs in your code.

Finally, I consider your name-calling defamatory; please desist from making false statements about me with the intention of making other people think worse of me.

Optimizers exploiting UB

Posted Jul 19, 2024 14:34 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

I got the point.

It's a bit like a sequence of integer multiplies and divides. *I* may know that if I do them in the correct order, I will get the correct result without either over- or under-flow, but if some clever idiot loses my parentheses in the bowels of the compiler, then the computer will get it wrong. Equally, if I'm used to the compiler doing it left-to-right, and then a slight change makes the compiler do it right-to-left. It's the law of unintended consequences, writ large, and the continual flow of new optimisers writs it ever larger :-)

Hence the stream of people moaning about it as they get bitten out of the blue ...

Cheers,
Wol

Optimizers exploiting UB

Posted Jul 19, 2024 15:02 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> It's a bit like a sequence of integer multiplies and divides. *I* may know that if I do them in the correct order

... but do you, really? Have you proven that your specified ordering does the right thing on all possible inputs?

(On a near-daily basis I have to deal with the consequences of arithmetic overflow and issues relating to integer precision)

> will get the correct result without either over- or under-flow, but if some clever idiot loses my parentheses in the bowels of the compiler, then the computer will get it wrong. Equally, if I'm used to the compiler doing it left-to-right, and then a slight change makes the compiler do it right-to-left. It's the law of unintended consequences,

This is a poor example; operator evaluation order (including explicit evaluation ordering signified by use of parenthesis) is part of the core language specification, and compilers can't (and don't) muck with that.

Optimizers exploiting UB

Posted Jul 19, 2024 15:25 UTC (Fri) by adobriyan (subscriber, #30858) [Link]

> (including explicit evaluation ordering signified by use of parenthesis)

What are you talking about? The evaluation order of "x = a + (b + c);" is "anything".