Related articles |
---|
[24 earlier articles] |
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) |
Re: Undefined Behavior Optimizations in C dave_thompson_2@comcast.net (2023-01-28) |
From: | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
Newsgroups: | comp.compilers |
Date: | Sat, 21 Jan 2023 11:54:43 GMT |
Organization: | Institut fuer Computersprachen, Technische Universitaet Wien |
References: | 23-01-027 <sympa.1673343321.1624.383@lists.iecc.com> 23-01-031 23-01-041 23-01-062 23-01-065 23-01-067 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="61901"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, optimize |
Posted-Date: | 21 Jan 2023 22:40:50 EST |
Thomas Koenig <tkoenig@netcologne.de> writes:
>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,
What makes you think so? The definition of ADDU in MIPS IV Rev. 3.2
is pretty perverse, specifying an undefined result if one of the
operands is not a sign-extended 32-bit value; but if both operands are
to the instruction's liking, it produces a sign-extended 32-bit
result.
A programming note says:
|[ADDU] is appropriate for arithmetic which is not signed, such as
|address arithmetic, or integer arithmetic environments that ignore
|overflow, such as āCā language arithmetic.
One interesting aspect is that the Power ABI specifies sign-extension
rather than garbage-extension for passing around ints. Many other
ABIs are similar (e.g., the RISC-V ABI specifies sign extension, even
for unsigned ints), and AMD64 specifies zero-extension for both signed
and unsigned ints (and has instructions that generate zero-extended
results).
- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.