llvm dev - Apr 2016 - Little explanation of this behaviour

Thanks, so what’s the point of these rules? Do they grant something like safety
or faster execution?
> C and C++ have what's called "integer promotion rules", which
apply to
> most expressions involving types smaller than int and insert an
> implicit promotion to int before anything else happens (in this case
> another implicit conversion to double).
> 
>> Can a sitofp i8 %3 to double be done or is it wrong?
> 
> That's fine, in fact LLVM optimizes the function to use that itself.
Are you saying that instruction will be optimized by LLVM in this case?

On 14 April 2016 at 16:23, Lorenzo Laneve <lore97drk at icloud.com>
wrote:
> Thanks, so what’s the point of these rules? Do they grant something like
safety or faster execution?
My guess is just backwards compatibility from the earliest C compilers
(where it might even have been simply to make implementation easier).
There's certainly no real safety benefits.

I suppose it does tend to match how the instructions actually get
implemented (most backends will use an 32-bit addition even for an
incoming "add i8 %l, %r") so exposing that early might give more
optimization opportunities, but that's a bit tenuous.
> Are you saying that instruction will be optimized by LLVM in this case?
Yes. LLVM will convert the "%int32 = sext i8 %val to i32; %res sitofp i32
%int32 to double" sequence into "%res = sitofp i8 %val to
double".

Cheers.

Tim.

On Fri, Apr 15, 2016 at 12:36 PM, Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 14 April 2016 at 16:23, Lorenzo Laneve <lore97drk at icloud.com>
wrote:
> > Thanks, so what’s the point of these rules? Do they grant something
like
> safety or faster execution?
>
> My guess is just backwards compatibility from the earliest C compilers
> (where it might even have been simply to make implementation easier).
> There's certainly no real safety benefits.
>
> I suppose it does tend to match how the instructions actually get
> implemented (most backends will use an 32-bit addition even for an
> incoming "add i8 %l, %r") so exposing that early might give more
> optimization opportunities, but that's a bit tenuous.
>
> > Are you saying that instruction will be optimized by LLVM in this
case?
>
> Yes. LLVM will convert the "%int32 = sext i8 %val to i32; %res >
sitofp i32 %int32 to double" sequence into "%res = sitofp i8 %val to
> double".
>
Many or most CPUs don't even have narrower size adds or subtracts --
smaller values get zero or sign extended when loaded from memory, worked on
in full register size, and truncated when written back to memory.

The PDP-11 was like that. There was a bit in the instruction encoding to
specify word or byte operand, and this worked with mov and cmp, but what
you'd think would be the encoding for add.b in fact turns out to be sub!

x86 and 68k can do arithmetic on different size operands directly, but
RISCs in general can't. Aarch64 is quite unusual in having a instruction
bit to specify 64 or 32 bit operations -- I'm expecting this means ARM will
eventually introduce low end implementations with a 32 bit ALU and 64 bit
operations will take longer. That's *not* the case with at A53 and A57, but
I haven't had a chance to look at the A35 specs yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160415/a635b64b/attachment.html>