[LLVMdev] Troubling promotion of return value to Integer ...

[Chris Lattner]

On May 16, 2008, at 11:12 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com 
 > wrote:

>
> Chris,
> I did not quite understand the “The bad thing about …” part of your  
> argument. I’m not sure which of the two scenarios are you comparing  
> (promoting in FrontEnd vs BackEnd) or (promotion to int vs i32)

Assume we make the change I suggested.  This means that this C  
function (on x86-32):

char foo() {
   char c = ...
   return c;
}

would compile to something like:

define i32 @foo() {
    ...
    %tmp = sext i8 ... to i32
    ret i32 %tmp
}

Since "char" is sign extend to 32 bits on this target, there would be  
an explicit sign extension.  This is goodness.  The problem is that  
now you have a caller:

  ...
char bar() {
   char x = foo()
   return char;
}

This would get compiled (by the front-end to something like this:

define i32 @bar() {
   ; call
   %tmp = call i32 @foo()
   %x = trunc i32 %tmp to i8

   ; return
   %tmp2 = sext i8 to i32
   ret i32 %tmp2
}

The problem with this is that we now have a trunc+sext instruction  
that cannot be eliminated.  The loss here is that while foo returns an  
i32 value, we lost the fact that the top 25 bits all have the same  
value (i.e. that it is a sign extended 8-bit value).  Because of this,  
we can't eliminate the trunc+sext pair in bar, pessimizing code (and  
in a very common case!).  I am just saying that we should have some  
attribute (or something) on foo that indicates its result is actually  
sign extended, allowing the optimizer to zap the trunc+sext in bar.


> The standard allows calling a function without prototype and assumes  
> “int” return value; and I realize that this is the primary reason  
> why the return value is being promoted. This ties this promotion to  
> int type and not the size of any register in target, which in turn  
> makes it a language issue rather than code generation issue; hence  
> FrontEnd must take care of it.

Right, I agree this should be fixed.

>
> Now for our port, things are different. In most (sane) ports, the  
> target provides an integer class for int… however, things are  
> different in our (insane) port. We only have an 8-bit data bus but  
> we also want 16-bit int type. So this promotion will make char  
> return values (which are used heavily in many application in 8-bit  
> environment) quite inefficient. So we need a way to turn off this  
> promotion all together and deal with default function prototype in a  
> different way (perhaps issue a diagnostic …)

Sure.  The other good thing about exposing this extensions in the IR  
is that interprocedural optimizations can eliminate them.  This gives  
the optimizer the ability to actually eliminate the extensions and  
truncations completely.

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