[LLVMdev] global type legalization?

[Chris Lattner]

On Sep 14, 2010, at 11:37 AM, Bob Wilson wrote:
>> 
>>> For ARM and possibly other RISC-like targets, you simply can't define an i8 or i16 value -- those aren't legal types.  Since those values will always be extended at the point where they are defined, the code placement problem is straightforward: you always want to fold the extends into the def, as long as the value is always extended the same way (not mixed sign and zero extends).  Whole function selection DAGs would make that easy.
>> 
>> Right.  This is a bit trickier than you make it sound though, because an "i8" addition isn't neccessarily zero or sign extended when the add is done in a 32-bit register.
> 
> When you pointed this out earlier, I conceded that I was wrong, but on second thought, I'm surprised that llvm uses i8 adds.  Other compilers that I've worked on rely on the integral promotion rules for C/C++ to convert all integer arithmetic to the default "int" or "unsigned" type.  That tends to work out nicely for register-oriented targets.  Is there a reason why llvm does not take that approach?

It's basically to canonicalize the IR and generate simpler code.  You can see that clang does do the integer promotions:

$ cat t.c 

char x, y, z;

void foo() {
  x = y+z;
}

$ clang t.c -emit-llvm -S -o - | opt -mem2reg -S
...
define void @foo() nounwind ssp {
entry:
  %tmp = load i8* @y, align 1
  %conv = sext i8 %tmp to i32
  %tmp1 = load i8* @z, align 1
  %conv2 = sext i8 %tmp1 to i32
  %add = add nsw i32 %conv, %conv2
  %conv3 = trunc i32 %add to i8
  store i8 %conv3, i8* @x, align 1
  ret void
}

But instcombine cleans up the IR:

define void @foo() nounwind ssp {
entry:
  %tmp = load i8* @y, align 1
  %tmp1 = load i8* @z, align 1
  %add = add i8 %tmp, %tmp1
  store i8 %add, i8* @x, align 1
  ret void
}

I think that the clean and simpler IR without extensions is more useful for other mid-level optimizations.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100914/04c19ef3/attachment.html>