search for: sign_ext_from_i1

...s Lattner wrote: >> n 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...

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...

...t 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 fo...

> > 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.

...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 b...

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

...8, 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. Th...

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. >...