Re: Undefined Behavior Optimizations in C

From	Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups	comp.compilers
Subject	Re: Undefined Behavior Optimizations in C
Date	2023-01-09 10:14 +0000
Organization	A noiseless patient Spider
Message-ID	<23-01-027@comp.compilers> (permalink)
References	<23-01-009@comp.compilers> <23-01-011@comp.compilers> <23-01-012@comp.compilers> <23-01-017@comp.compilers>

Show all headers | View raw

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Undefined Behavior Optimizations in C "Lucian Popescu" <lucic71@ctrl-c.club> - 2023-01-05 10:05 +0000
  RE: Undefined Behavior Optimizations in C "Nuno Lopes" <nuno.lopes@tecnico.ulisboa.pt> - 2023-01-05 10:24 +0000
  Re: Undefined Behavior Optimizations in C Spiros Bousbouras <spibou@gmail.com> - 2023-01-05 18:06 +0000
    Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-05 16:22 -0800
      Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-06 08:41 +0000
      Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-06 16:12 +0100
        Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-06 10:33 -0800
          Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-06 11:39 -0800
          Re: Undefined Behavior Optimizations in C Spiros Bousbouras <spibou@gmail.com> - 2023-01-07 12:10 +0000
            Re: Undefined Behavior Optimizations in C antispam@math.uni.wroc.pl - 2023-01-13 20:46 +0000
        Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 10:14 +0000
          Re: Re: Undefined Behavior Optimizations in C Jon Chesterfield <jonathanchesterfield@gmail.com> - 2023-01-10 10:46 +0000
            Re: Undefined Behavior Optimizations in C Thomas Koenig <tkoenig@netcologne.de> - 2023-01-11 09:34 +0000
              Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-12 05:21 +0000
                Re: Undefined Behavior Optimizations in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-12 12:21 -0800
                Re: Undefined Behavior Optimizations in C Thomas Koenig <tkoenig@netcologne.de> - 2023-01-12 21:50 +0000
                Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-15 04:17 +0000
            Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-11 14:20 +0100
              Re: Undefined Behavior Optimizations in C Spiros Bousbouras <spibou@gmail.com> - 2023-01-18 13:14 +0000
                Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-18 21:14 +0100
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-18 21:10 -0800
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-20 10:45 -0800
                Re: Undefined Behavior Optimizations in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 13:54 -0800
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-23 18:50 -0800
                Re: Undefined Behavior Optimizations in Fortran "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2023-01-26 21:12 +0000
                Re: Undefined Behavior Optimizations in Fortran gah4 <gah4@u.washington.edu> - 2023-01-26 17:50 -0800
                Re: Undefined Behavior Optimizations in C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2023-01-19 21:18 -0800
                Re: Undefined Behavior Optimizations in C Thomas Koenig <tkoenig@netcologne.de> - 2023-01-20 20:42 +0000
                Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-21 11:54 +0000
                Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-22 09:56 +0000
                Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-22 07:04 +0000
                Re: Undefined Behavior Optimizations in C Martin Ward <martin@gkc.org.uk> - 2023-01-23 17:12 +0000
          Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-10 17:32 +0100
            Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-10 15:57 -0800
              Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-11 14:40 +0100
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-11 16:09 -0800
            Re: Undefined Behavior Optimizations in C dave_thompson_2@comcast.net - 2023-01-28 10:35 -0500
  Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-06 07:47 +0000
  Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 09:10 +0000

csiph-web