<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 15, 2016 at 12:36 PM, Tim Northover via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14 April 2016 at 16:23, Lorenzo Laneve <<a href="mailto:lore97drk@icloud.com">lore97drk@icloud.com</a>> wrote:<br>
> Thanks, so what’s the point of these rules? Do they grant something like safety or faster execution?<br>
<br>
</span>My guess is just backwards compatibility from the earliest C compilers<br>
(where it might even have been simply to make implementation easier).<br>
There's certainly no real safety benefits.<br>
<br>
I suppose it does tend to match how the instructions actually get<br>
implemented (most backends will use an 32-bit addition even for an<br>
incoming "add i8 %l, %r") so exposing that early might give more<br>
optimization opportunities, but that's a bit tenuous.<br>
<span class=""><br>
> Are you saying that instruction will be optimized by LLVM in this case?<br>
<br>
</span>Yes. LLVM will convert the "%int32 = sext i8 %val to i32; %res =<br>
sitofp i32 %int32 to double" sequence into "%res = sitofp i8 %val to<br>
double".<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br></div></div></div></div>