search for: zero_ext_from_i16

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

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

...mp = sext i8 ... to i32 ret i32 %tmp } 3) Return value promotion is the default behavior, however, hooks will be provided to allow the Target to disable it and emit diagnostics. 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) Am I capturing everything? -A...

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

Hi, > 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) How will the...

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

On May 28, 2008, at 11:53 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: >> Ok. We already have this, with the 'signext' attribute. This code: >> >> signed char g(); >> signed char foo(){ >> return g(); >> } >> >> compiles into: >> >> define i8 @foo() signext nounwind {

...microchip.com Sent: Thursday, March 12, 2009 10:39 AM To: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] promotion of return value. 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. ____________________...

...lee side, then the caller takes the part that it needs and again promotes it to comply with the rules of integer promotion stuff, hence double promotion. What we are trying to do is to add new attributes (more maybe added later): > sign_ext_from_i8, sign_ext_from_i16 > zero_ext_from_i8, zero_ext_from_i16 to function definition so (assuming that both caller and callee are generated in the same front-end) the caller will know if the callee has already extended the return value or not, then it can promote only if needed. You may argue that this all can be done per a target-defined convention and I t...

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 for direct and indirect >> call. >> (syntax of these att...

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

Hi, > What we are trying to do is to add new attributes (more maybe added > later): > > > sign_ext_from_i8, sign_ext_from_i16 > > zero_ext_from_i8, zero_ext_from_i16 > > to function definition so (assuming that both caller and callee are > generated in the same front-end) the caller will know if the callee has > already extended the return value or not, then it can promote only if > needed. I don't understand what the point of this is. Sur...

...%tmp2 > } > What I'm getting at with this, is that if we compiled foo to include an attribute "sign_ext_from_i8" or something, then we could capture this information. It would be ugly, but acceptable to define: sign_ext_from_i8, sign_ext_from_i16 zero_ext_from_i8, zero_ext_from_i16 And have the C front-end generate these. Given this, the optimizer and codegen can continue doing their optimizations, and we can eventually eliminate the existing sext/zext attributes. Does this make sense? -Chris

On Mar 31, 2009, at 11:46 AM, Alireza.Moshtaghi at microchip.com wrote: > Any thoughts on this? > I would like to get it right before jumping into the nuts and bolts > of it…. Did you see this Ali? http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL:

...part that it needs and again promotes it to > comply with the rules of integer promotion stuff, hence double > promotion. > > What we are trying to do is to add new attributes (more maybe added > later): > >>   sign_ext_from_i8, sign_ext_from_i16 >>   zero_ext_from_i8, zero_ext_from_i16 > > to function definition so (assuming that both caller and callee are > generated in the same front-end) the caller will know if the callee has > already extended the return value or not, then it can promote only if > needed. > > You may argue that this all can be done per a...

>Ok, I'm not sure what issue you mean. Can you restate? I'm referring to your statement (below) where you say "there needs to be some attribute (or something) on foo". What I don't understand is I don't know who would be setting this attribute? Whatever you do, if you consider caller and callee are in different translation units, then all that we can know in the

...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 Mon, 19 May 2008 Alireza.Moshtaghi at microchip.com wrote: > Correction: > > The analysis I made regarding the callers knowledge of sign/zero > extension of return value is flawed. So I take it back. > > Never the less, I don't see how adding attributes would resolve this > problem either. Ok, I'm not sure what issue you mean. Can you restate? -Chris >

2009/3/12 <Alireza.Moshtaghi at microchip.com>: > What I was planning to do is to provide a default behavior that is > consistent with what currently llvm does (promote to 32 bit) > And then there will be control in clang for targets to do things > differently. > But I also understand you concern about gcc frontend; because the same > thing has to also take place there....

...What I'm getting at with this, is that if we compiled foo to include > an attribute "sign_ext_from_i8" or something, then we could capture > this information. It would be ugly, but acceptable to define: > > sign_ext_from_i8, sign_ext_from_i16 > zero_ext_from_i8, zero_ext_from_i16 > > And have the C front-end generate these. Given this, the optimizer > and codegen can continue doing their optimizations, and we can > eventually eliminate the existing sext/zext attributes. > > Does this make sense? > > -Chris > ___________________________________...