Re: Undefined Behavior Optimizations in C

Keith Thompson <Keith.S.Thompson+u@gmail.com>
Thu, 12 Jan 2023 12:21:40 -0800

          From comp.compilers

Related articles
[13 earlier articles]
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)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-18)
[10 later articles]
| List of all articles for this month |
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.compilers
Date: Thu, 12 Jan 2023 12:21:40 -0800
Organization: None to speak of
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="82638"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize
Posted-Date: 12 Jan 2023 20:53:07 EST

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> 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.


(It didn't.)


> 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.
[...]
> [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]


And in fact the C standard makes this explicit in this case, in a
footnote in the section defining the translation phases:


        Physical source file multibyte characters are mapped, in an
        implementation- defined manner, to the source character set
        (introducing new-line characters for end-of-line indicators) if
        necessary. Trigraph sequences are replaced by corresponding
        single-character internal representations. Implementations shall
        behave as if these separate phases occur, even though many are
        typically folded together in practice. Source files, translation
        units, and translated translation units need not necessarily be
        stored as files, nor need there be any one-to-one correspondence
        between these entities and any external representation. The
        description is conceptual only, and does not specify any particular
        implementation.


Of course any link-time optimization that breaks the standard-defined
semantics makes the implementation non-conforming (the same as for any
optimization).


--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */


Post a followup to this message

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