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

[Chris Lattner]

On May 28, 2008, at 11:53 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com 
 > wrote:
>> Ok.  We already have this, with the 'signext' attribute.  This code:
>>
>> signed char g();
>> signed char foo(){
>> 	return g();
>> }
>>
>> compiles into:
>>
>> define i8 @foo() signext nounwind  {
>> entry:
>> 	%tmp1 = tail call i8 (...)* @g( ) signext nounwind
> ; <i8>
>> [#uses=1]
>> 	ret i8 %tmp1
>> }
>>
>> declare i8 @g(...) signext
>>
>> Note that the 'signext' attribute is on all of foo, the call to G,  
>> and
>> the G declaration itself.
>>
>
> OK, so you are giving a new meaning to signext attribute, where in
> addition to parameters, now it would also be applicable to return  
> value
> of function.

It already applies to return values, as I show above.  That is code  
literally output by llvm-gcc today.

>
> (BTW I think it's a typo that you didn't promote the return value of  
> foo
> :)

No, that is what llvm-gcc generates today verbatim.

> I take it from your reply that, by using signext and implementing the
> two helper methods, which I mentioned before, there would be no need  
> to
> add any new function attributes; right?

I'm not sure what you mean.  signext is an attribute.

>>> The IR is already capturing this much information.  If you want to  
>>> go
>> this route, it seems simple to parameterize (in target data?) the  
>> size
>> of int, and have the code generator extend to that size, instead of
>> forcing extension to i32.
>
> Yes, I meant the same...

On further reflection, I actually like the idea of adding 4 attributes  
better than adding knowledge of "int" into TargetData.  "int" is a C  
notion that doesn't really belong in TargetData, and it is better for  
the optimizers to have the front-end expose the implicit promotions.

-Chris