Re: Undefined Behavior Optimizations in C

On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
> On 06/01/2023 01:22, gah4 wrote:
>> 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.
>
> The trouble with undefined behaviour is that, in general, you cannot
> trust the compiler to "do what you say" because it cannot know what you
> have said.


That's correcst; however, what we should be able to trust is for the
compiler not to make it worse.


The compiler makes it worse when it assumes that the programmer is
infallible, and thus makes logical inferences predicated on some
construct never having undefined behavior, using those to guide the
translation of other constructs.


This is particularly harmful when the undefined behavior is *de facto*
defined: like that if the undefinedness aspect is ignored, and the
obvious code is emitted, that code will do something characteristic
of the machine.


In C99, the original definition of undefined behavior is this:


    behavior, upon use of a nonportable or erroneous program construct or
    of erroneous data, for which this International Standard imposes no
    requirements.


    NOTE: Possible undefined behavior ranges from ignoring the situation
    completely with unpredictable results, to behaving during translation
    or program execution in a documented manner characteristic of the
    environment (with or without the issuance of a diagnostic message), to
    terminating a translation or execution (with the issuance of a
    diagnostic message).


There is an obvious intepretation of this text which rules out
the too-clever optimizations.


If the compiler optimizes construct Y based on some other construct
X being free of undefined behavior, and that assumption turns
out to be false, that compiler has not conformed to the "NOTE"
part of the treatment of undefined behavior.


Firstly, it has not "ignor[ed] the situation completely". You cannot
assume that X is well-defined, in order to treat Y in some way, and yet
say that you're completely ignoring the situaton of X. If the UB
problem in X causes a secondary problem with the way Y was translated,
that is a problem with the assumption that was made about X. That
assumption was made because it's possible for X to be undefined, and
that possiblity was expliclty disregarded, which is not the same as
completely ignored.


The situation also isn't a documented manner characteristic of
the environment.


It also isn't a termination of translation or execution with or without
a diagnostic message.


The situation doesn't conform to the NOTE.


C compiler writers should take the NOTE more seriously.


Ignoring the situation completely must mean something like:


"Do not engage in any reasoning about whether the inputs or other
conditions are right for the correct execution of the construct. Do not
handle the bad situations at translation time, and don't emit any code
to handle them. Just translate the specified semantics, and let the
translated language and its run-time deal with those potential issues."


As soon as we assume that, oh, if X is well-defined, we can make a
certain shortcut in translating this other construct Y, we are no longer
"completely ignoring"; we are engaging in reasoning about whether the
inputs or other conditions are right for the correct execution of X, and
insisting that they must be, as a justification for treating Y in a
certain way.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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