Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!feeder.erje.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Subject: Re: Undefined Behavior Optimizations in C
Date: Sat, 21 Jan 2023 11:54:43 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Sender: johnl@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <23-01-069@comp.compilers>
References: <23-01-027@comp.compilers> <sympa.1673343321.1624.383@lists.iecc.com> <23-01-031@comp.compilers> <23-01-041@comp.compilers> <23-01-062@comp.compilers> <23-01-065@comp.compilers> <23-01-067@comp.compilers>
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
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:3337

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/