Related articles |
---|
[14 earlier articles] |
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) |
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) |
[9 later articles] |
From: | Thomas Koenig <tkoenig@netcologne.de> |
Newsgroups: | comp.compilers |
Date: | Thu, 12 Jan 2023 21:50:14 -0000 (UTC) |
Organization: | news.netcologne.de |
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="83074"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, optimize |
Posted-Date: | 12 Jan 2023 20:53:51 EST |
Kaz Kylheku <864-117-4973@kylheku.com> schrieb:
> 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.
[...]
The C standard (like other programming language standards) describes
behavior, not implementation. A compiler which translates "as if" the
phases were followed works as well. The same applies to program
execution, where the concept of the abstract machine is used.
Regarding compilation phases, this is made clear in N2596,
5.1.1.2 Translation phases
The precedence among the syntax rules of translation is specified
by the following phases.6)
plus the footnote which explains a bit what is meant by
6) This requires implementations to behave as if these separate
phases occur, [...]
> 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.
... which does not have to be the case.
> When the compiler/linker peeks into translation unit a.o in order to
> alter something in b.o, you no longer have translation units.
... which you don't need; 5.1.1.2 shows the "as if" rule quite clearly.
If LTO changes the semantics of a standard-conforming program, that
is another matter; that is then simply a bug.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.