Re: Undefined Behavior Optimizations in C

Kaz Kylheku <864-117-4973@kylheku.com>
Thu, 12 Jan 2023 05:21:16 -0000 (UTC)

          From comp.compilers

Related articles
[12 earlier articles]
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-10)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-10)
Re: Undefined Behavior Optimizations in C tkoenig@netcologne.de (Thomas Koenig) (2023-01-11)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-11)
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)
[11 later articles]
| List of all articles for this month |

From: Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups: comp.compilers
Date: Thu, 12 Jan 2023 05:21:16 -0000 (UTC)
Organization: A noiseless patient Spider
References: 23-01-027 <sympa.1673343321.1624.383@lists.iecc.com> 23-01-031 23-01-036
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="11680"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize, comment
Posted-Date: 12 Jan 2023 13:37:40 EST

On 2023-01-11, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Jon Chesterfield <jonathanchesterfield@gmail.com> schrieb:
>> It annoys me intensely that the type aliasing rules capture something a
>> whole program optimising compiler can usually work out for itself anyway,
>
> Link-time optimization, while highly useful, currently has severe
> scaling issues. This is an area where advances would be really
> useful (if implemented in production compilers).


Link-time optimization violates ISO C, unfortunately.


ISO C describes C translation in a number of phases. I'm going to use
C99 numbering; it might have changed in C11.


In translation phase 7, syntax and semantic analysis is performed on the
tokens coming from the previous phases (preprocessing) and the
translation unit is translated.


Then in translation phase 8, multiple translation units are combined,
and references are resolved.


Link time optimization breaks the layering; it reintroduces semantic
analysis into translation phase 8, where only linking is supposed to be
taking place.


When the compiler/linker peeks into translation unit a.o in order to
alter something in b.o, you no longer have translation units.


You have something similar to the effect of doing


    cat a.c b.c > combined.c
    cc combined.c


except that such a crude approach combines all internal linkage
identifiers ("static") into one.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[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]


Post a followup to this message

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