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

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

> 
> 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. 
Does this also apply to Evan's proposal?

A.

On Jun 9, 2008, at 12:43 PM, <Alireza.Moshtaghi at microchip.com>
<Alireza.Moshtaghi at microchip.com
 > wrote:
>
>>
>> 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.
>
> Does this also apply to Evan's proposal?
What do you mean?

-Chris

I think the "answer" is yes. Given the attributes are a bitfield, it  
would be difficult to encode any arbitrary type. I am happy with just  
adding sign_ext_from_i1 and zero_ext_from_i1 for now. That's  
progress! :-)

Evan

On Jun 9, 2008, at 12:43 PM, Alireza.Moshtaghi at microchip.com wrote:
>
>>
>> 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.
>
> Does this also apply to Evan's proposal?
>
> A.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev