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

[Chris Lattner]

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