search for: zero_ext_from_i1

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

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

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

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

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

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

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

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

Previously we talked about adding new attributes to function to identify the promotion class. > sign_ext_from_i8, sign_ext_from_i16 > zero_ext_from_i8, zero_ext_from_i16 Aren't these attributes more applicable to return value? of course then the question would be if they are also applicable to parameters too? (because we use same attributes for parameters and return value)? or should we disallow then on parameters? Thoughts? A. __________________________...

...lue promotion is the default behavior, however, > hooks will be provided to allow the Target to disable it > and emit diagnostics. Sure, the front-end can do that. > 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...