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

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

On Jun 4, 2008, at 10:52 AM, Evan Cheng wrote:
>
> 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?
What would that mean? Can you give an example?

-Chris

On Jun 4, 2008, at 11:12 AM, Chris Lattner wrote:
>
> On Jun 4, 2008, at 10:52 AM, Evan Cheng wrote:
>
>>
>> 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?
>
> What would that mean? Can you give an example?
Well, you suggested sext / zext from i8 / i16. Why not from i1 (useful  
for denoting boolean type) or any arbitrary type?

Evan
>
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jun 6, 2008, at 03:04, Evan Cheng wrote:
> On Jun 5, 2008, at 11:44 PM, Chris Lattner wrote:
>
>> On Jun 5, 2008, at 11:33 PM, Evan Cheng wrote:
>>
>>> On Jun 4, 2008, at 11:12 AM, Chris Lattner wrote:
>>>
>>>> On Jun 4, 2008, at 10:52 AM, Evan Cheng wrote:
>>>>
>>>>> 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?
>>>>
>>>> What would that mean? Can you give an example?
>>>
>>> Well, you suggested sext / zext from i8 / i16. Why not from i1  
>>> (useful for denoting boolean type) or any arbitrary type?
>>
>> Are you suggesting adding 'sign_ext_from_i1' and
'zero_ext_from_i1'
>> attributes?  I'd be fine with that.  It would also solve some  
>> existing code quality issues we have.
>
> These will be useful. But is it possible to be more generic?  
> sext_from type where type can be any type? The value of the  
> attribute would somehow tells us the type before extension?

Why not the values codegen is actually looking for? Say, these  
attributes:

     known_bits(mask, bits) ; Partially known values.
     sign_bits(num)         ; Number of leading sign extended bits.

Example:

     ; unsigned char f(bool, signed char)
     define i32 known_bits(0xFFFFFF00, 0)
            @f(i32 known_bits(0xFFFFFFFE, 0) %b,
               i32 sign_bits(25) %c)

If the attribute values were encoded as constants, these could even  
generalize to aggregate return:

     ; struct S { bool b; signed char c; };
     ; struct S f();
     ; S s = f();
     %s = call {i32, i32} known_bits({i32, i32} {i32 0xFFFFFFE, i32 0})
                          sign_bits({i8, i8} {i8 0, i8 25})
               @f();

     ; Easy to propagate known bits and sign bits from %s to %s.b and  
%s.c.
     %s.b = getelement {i32, i32} %s, 0
     %s.c = getelement {i32, i32} %s, 1

— Gordon

On Jun 6, 2008, at 6:02 AM, Gordon Henriksen wrote:
>> These will be useful. But is it possible to be more generic?
>> sext_from type where type can be any type? The value of the
>> attribute would somehow tells us the type before extension?
>
> Why not the values codegen is actually looking for? Say, these
> attributes:
>
>     known_bits(mask, bits) ; Partially known values.
>     sign_bits(num)         ; Number of leading sign extended bits.
Yes, this would be much nicer.  The only issue is that attributes are  
currently a bitfield, so they can't be parameterized. I'd love to see  
this get fixed.  Another issue with attributes is that they can't be  
applied to multiple results as you say.  I'm not sure what the right  
fix is, but I don't think your approach will work for other  
attributes.  How would you say that the first pointer result is  
guaranteed non-null but the second isn't for example?

-Chris
>
>
> Example:
>
>     ; unsigned char f(bool, signed char)
>     define i32 known_bits(0xFFFFFF00, 0)
>            @f(i32 known_bits(0xFFFFFFFE, 0) %b,
>               i32 sign_bits(25) %c)
>
> If the attribute values were encoded as constants, these could even
> generalize to aggregate return:
>
>     ; struct S { bool b; signed char c; };
>     ; struct S f();
>     ; S s = f();
>     %s = call {i32, i32} known_bits({i32, i32} {i32 0xFFFFFFE, i32 0})
>                          sign_bits({i8, i8} {i8 0, i8 25})
>               @f();
>
>     ; Easy to propagate known bits and sign bits from %s to %s.b and
> %s.c.
>     %s.b = getelement {i32, i32} %s, 0
>     %s.c = getelement {i32, i32} %s, 1
>
> — Gordon
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev