llvm dev - Jun 2008 - [LLVMdev] Troubling promotion of return value to Integer ...

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

> 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.
This is very true and indeed applicable to this problem...
So I have to agree :)

Let me summarize what we discussed so far:

1) The return value promotion will be removed from llvm backend and 
   implemented in both front-ends (clang and llvm-gcc)

2) The promotions are only applied to the return value in the body 
   of the function. 
   Return value of function definition and declaration will not be
promoted
   
   Example for a Target with 32-bit int type:

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

   Is translated to:

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

3) Return value promotion is the default behavior, however, 
   hooks will be provided to allow the Target to disable it
   and emit diagnostics.

4) There will be 4 new function attributes:
   sign_ext_from_i8, sign_ext_from_i16
   zero_ext_from_i8, zero_ext_from_i16
   These attributes will be placed on the function CALL node by
front-end
   to inform the backend about such promotions and enable optimization
of 
   return value. This should be sufficient for direct and indirect call.
   (syntax of these attributes to be defined)

Am I capturing everything?

-Ali.

Hi,
> 4) There will be 4 new function attributes:
>    sign_ext_from_i8, sign_ext_from_i16
>    zero_ext_from_i8, zero_ext_from_i16
>    These attributes will be placed on the function CALL node by front-end
to
>    inform the backend about such promotions and enable optimization of
>    return value. This should be sufficient for direct and indirect call.
>    (syntax of these attributes to be defined)
How will these attributes work with functions returning multiple values? AFAIK
it is currently not possible to have seperate attributes for each of the
return values (since multiple return values are actually one struct).

Even though our C frontends will probably not be generated functions that
return multiple values, a later optimization pass might introduce extra return
values. In this case, can these attributes be preserved in some way, or
perhaps just thrown away (causing only slower code, not miscompilation)?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080530/2086e901/attachment.sig>

On May 29, 2008, at 10:30 AM, <Alireza.Moshtaghi at microchip.com>
<Alireza.Moshtaghi at microchip.com
 > wrote:
>
>> 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.
>
> This is very true and indeed applicable to this problem...
> So I have to agree :)
>
> Let me summarize what we discussed so far:
>
> 1) The return value promotion will be removed from llvm backend and
>   implemented in both front-ends (clang and llvm-gcc)
>
> 2) The promotions are only applied to the return value in the body
>   of the function.
>   Return value of function definition and declaration will not be
> promoted
>
>   Example for a Target with 32-bit int type:
>
>   char foo() {
>     char c = ...
>     return c;
>   }
>
>   Is translated to:
>
>   define i8 @foo() {
>      ...
>      %tmp = sext i8 ... to i32
>      ret i32 %tmp
>   }
Close.  The return value of declarations also has to be promoted.  foo  
should be translated to:
>   define i32 @foo() sign_ext_from_i8 {
>      ...
>      %tmp = sext i8 ... to i32
>      ret i32 %tmp
>   }
> 3) Return value promotion is the default behavior, however,
>   hooks will be provided to allow the Target to disable it
>   and emit diagnostics.
Sure, the front-end can do that.
> 4) There will be 4 new function attributes:
>   sign_ext_from_i8, sign_ext_from_i16
>   zero_ext_from_i8, zero_ext_from_i16
>   These attributes will be placed on the function CALL node by
> front-end
>   to inform the backend about such promotions and enable optimization
> of
>   return value. This should be sufficient for direct and indirect  
> call.
>   (syntax of these attributes to be defined)
They also go on the function definition, as above.
> Am I capturing everything?
Yep!  The place to start with this is introducing the new attributes.   
Given the new attributes, we can mock up .ll code that uses them and  
improve the optimizers to use them.  When everything there is correct,  
we can move each front-end over to start using them.

-Chris

On May 29, 2008, at 10:30 AM, Alireza.Moshtaghi at microchip.com
wrote:
>
>
> 4) There will be 4 new function attributes:
>   sign_ext_from_i8, sign_ext_from_i16
>   zero_ext_from_i8, zero_ext_from_i16
>   These attributes will be placed on the function CALL node by
> front-end
>   to inform the backend about such promotions and enable optimization
> of
>   return value. This should be sufficient for direct and indirect  
> call.
>   (syntax of these attributes to be defined)
Should we go one step further and provide an attribute whose value is  
the "original type" before the extension?

Evan
>
>
> Am I capturing everything?
>
> -Ali.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev