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

Chris Lattner sabre at nondot.org
Fri May 16 06:11:09 PDT 2008


On May 14, 2008, at 10:43 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com 
 > wrote:

> In this thread I’m trying to merge two email threads into one,  
> because both discuss the same problem that’s troubling us and I  
> would like to reach a conclusion on what would be the best approach.
> To minimize the size of this thread I only mention the subject of  
> the other two threads:
> (1)    [LLVMdev] Integer promotion of return node operand         
> (initiated by Sachin)
> (2)    [LLVMdev] trouble with 32-bit promotion of return value    
> (initiated by myself)
>
> To summarize:
> Evan has replied to thread (1) and suggested to add a calling  
> convention and check for it in visitRet
> Dan replied to thread (2) and suggested to add a new field to the  
> TargetLowering class, and then let each target specify the minimum  
> integer type to promote return types to
>
> Either way, I think we all agree that the root of the problem is the  
> FIXME in SelectionDAGLowering::visitRet()

Hi Ali,

I think there are two sides to this issue.  The ultimate problem is  
that the code generator has a builtin assumption that sizeof(int) = 32  
bits.  IIRC, this comes into play in two places:

1. Arguments to calls are known to be sign/zero extended to int in  
certain cases.
2. The return value of functions is implicitly promoted.

Lets talk about #2 first, because it is the simplest case.  Here the  
front-end types the function as (f.e.) returning i8, and then has the  
code generator insert the extension to (for example) i32.  The  
attribute on the function tells the code generator whether to sign or  
zero extend it.

To me, the solution to this is to have the C front-end insert an  
explicit extension of the appropriate type to the right size.  This  
would mean that the code generator would now never insert the  
extension.  Since the C front-end knows the size of int, on your  
target, you could have it extend to 16 or 8 bits, as appropriate.   
This is also good, because the extension is exposed to the mid-level  
optimizer, allowing it to be eliminated more aggressively.

The bad thing about doing this is that, on the caller side, we lose  
information.  With the current approach, the caller knows that the  
value is (for example) 8 bits but sign or zero extended as  
appropriate.  This allows the caller side to do optimizations based on  
this fact.  If all return values were i32, we wouldn't know that the  
top 24 bits were sign/zero extended.  I think we can handle this by  
adding some new attributes, but this is marginally ugly.

What do you think?

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


More information about the llvm-dev mailing list