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

Chris Lattner sabre at nondot.org
Fri May 16 08:49:35 PDT 2008


On May 16, 2008, at 8:45 AM, Jonathan S. Shapiro wrote:

> On Fri, 2008-05-16 at 06:11 -0700, Chris Lattner wrote:
>
>> 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.
>
> Opinion:
>
> The front end should be responsible for introducing all necessary
> promotions, sign extensions, or zero extensions. The absence of these
> operations where required is a type error in the emitted IR, and  
> should
> be treated as such. The job of the back end is to reject ill-typed  
> input
> as malformed, not correct it. Therefore, the code generator should not
> be inserting these promotions.

Actually, the code generator only accepts well formed code.  The front- 
end is responsible for rejecting invalid code.

>> 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.
>
> The real issue here is that there is a divergence between the logical
> type and the representation type, the back end needs to know both for
> different purposes, and within the constraints of the current IR  
> (absent
> new annotations) information about one or the other is lost.

This is a representational issue, not a philisophical one.  The  
question is where to expose the operation, not whether to do so.  The  
sign/zero extension must be done.

-Chris



More information about the llvm-dev mailing list