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

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

Going that route, and with 64 bit processors picking up, I'm sure soon
we will have to add two more new attributes:
sign_ext_from_i32 and zero_ext_from_i32
which makes the number of attributes 8 (i1,i8,i16,i32) rather than 4
(i8,i16)

Is this exactly what is desired? From one perspective it is good because
it doesn't require too much modification. On the other hand the way that
attributes are designed does not allow much flexibility and I'm sure in
future the same kind of discussion, but about some other attribute, will
pop up on this email list...

A.

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
On
> Behalf Of Evan Cheng
> Sent: Tuesday, June 10, 2008 12:10 AM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Troubling promotion of return value to Integer
...
> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jun 10, 2008, at 2:36 PM, <Alireza.Moshtaghi at microchip.com>
<Alireza.Moshtaghi at microchip.com
 > wrote:
> Going that route, and with 64 bit processors picking up, I'm sure soon
> we will have to add two more new attributes:
> sign_ext_from_i32 and zero_ext_from_i32
> which makes the number of attributes 8 (i1,i8,i16,i32) rather than 4
> (i8,i16)
>
> Is this exactly what is desired? From one perspective it is good  
> because
> it doesn't require too much modification. On the other hand the way  
> that
> attributes are designed does not allow much flexibility and I'm sure  
> in
> future the same kind of discussion, but about some other attribute,  
> will
> pop up on this email list...
It really depends on how much you want to do.  If you're interested in  
doing the work to make attributes parameterized, it is clearly the  
right way to go.  If you're not interested in that, adding 8  
attributes on demand is ok.

-Chris