Re: Undefined Behavior Optimizations in C

Kaz Kylheku <864-117-4973@kylheku.com>
Sun, 15 Jan 2023 04:17:31 -0000 (UTC)

          From comp.compilers

Related articles
[16 earlier articles]
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-11)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-11)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-12)
Re: Undefined Behavior Optimizations in C Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-12)
Re: Undefined Behavior Optimizations in C tkoenig@netcologne.de (Thomas Koenig) (2023-01-12)
Re: Undefined Behavior Optimizations in C antispam@math.uni.wroc.pl (2023-01-13)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-15)
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-18)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-18)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-18)
Re: Undefined Behavior Optimizations in C alexfrunews@gmail.com (Alexei A. Frounze) (2023-01-19)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-20)
Re: Undefined Behavior Optimizations in C tkoenig@netcologne.de (Thomas Koenig) (2023-01-20)
[7 later articles]
| List of all articles for this month |
From: Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups: comp.compilers
Date: Sun, 15 Jan 2023 04:17:31 -0000 (UTC)
Organization: A noiseless patient Spider
References: 23-01-027 <sympa.1673343321.1624.383@lists.iecc.com> 23-01-031 23-01-036 23-01-045
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="38641"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize, comment
Posted-Date: 15 Jan 2023 13:09:50 EST

On 2023-01-12, the moderator wrote:
> [I don't see the problem, since there's invariably an "as if" rule
> that lets you do whatever you want so long as the results are the same
> as if you'd done everything in sequence. If a linktime optimizer looks
> at the code, promotes a couple of very busy variables that never have
> their addresses taken into global registers, so what? Or if it can
> globally tell that two variables are never aliased so it can reuse a
> register copy of one after modifying the other, again so what? -John]


We can look at this as if the translation units have been rolled back in
time to translation phase 7, where semantic analysis is now taking place
again in an aternative future. This time, there is a magic oracle
present that provides information about all the translation units
which will be linked to produce the program.


I'm skeptical whether the GCC and Clang LTO systems always behave like a
magic oracle that supplies iron-clad truths to translation phase 7.


And even if so, it seems wrong for the translation phase semantic
analysis to be looking at information from any other part of a program
than the translation unit at hand. The standard clearly says what is
subject to semantic analysis, and it's only the material from the
translation unit:


    7. White-space characters separating tokens are no longer significant.
          Each preprocessing token is converted into a token. The resulting
          tokens are syntactically and semantically analyzed and translated
          as a translation unit.


"The resulting tokens" are those from this translation unit, and nowhere
else. Nothing other than those tokens is to be semantically analyzed.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[Hey, wait, it's one thing to say LTO might be buggy, another to say
it's fundamentally imposible. Any optimizer might be buggy. -John]


Post a followup to this message

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