Re: Undefined Behavior Optimizations in C

Thomas Koenig <tkoenig@netcologne.de>
Fri, 20 Jan 2023 20:42:25 -0000 (UTC)

          From comp.compilers

Related articles
[22 earlier articles]
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)
Re: Undefined Behavior Optimizations in C Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-20)
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-21)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-22)
Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (2023-01-22)
Re: Undefined Behavior Optimizations in C martin@gkc.org.uk (Martin Ward) (2023-01-23)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-23)
[1 later articles]
| List of all articles for this month |

From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.compilers
Date: Fri, 20 Jan 2023 20:42:25 -0000 (UTC)
Organization: news.netcologne.de
References: 23-01-027 <sympa.1673343321.1624.383@lists.iecc.com> 23-01-031 23-01-041 23-01-062 23-01-065
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="53399"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize
Posted-Date: 20 Jan 2023 16:14:34 EST

Alexei A. Frounze <alexfrunews@gmail.com> schrieb:


> I believe in a case like this a modern C/C++ compiler reasons that x must be
> less than the maximum representable value and it generates code according
> to this, possibly removing dead code that depends on x being the maximum
> representable value. If the compiler's assumption that x is less than the
> maximum is wrong, it's perfectly fine, it's UB, any "broken" code generated
> is allowed.


There are cases when compilers don't even use this knowledge.


Take the function


int add (int a, int b)
{
        return a+b;
}


on an instruction set architecture which has only 64-bit
arithmetic, such as POWER. This is translated by gcc,
with optimization, to


                add 3,3,4
                extsw 3,3
                blr


(which is an addition followed by a sign extension). The POWER ABi
specifies that all values passed in registers are sign-extended,
so the content of a register has the same value independent of
the width of the signed integer it is being considered as.


So, the compiler would be within its right to _not_ extend the sign
of the result, because it could assume that no overflow occurs.
This, however, would result in a violation of the ABI, so the
compiler puts in the extra instruction just in case. If you
replace int by long in the example above, the sign extension
instruction is not generated.


By comparision, MIPS gcc translates this to


                jr $31
                addu $2,$4,$5


(note use of the delay slot), so no explicit sign extension is done,
and the value returned in the register might have a different value
if interpreted as a 64-bit value.



Post a followup to this message

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