search for: sign_ext_from_i16

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

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

...define i8 @foo() { ... %tmp = 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 d...

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

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

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

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 {

...uiuc.edu] On Behalf Of Alireza.Moshtaghi at 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?...

...ively promoting the return value on the callee 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 d...

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

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

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

...%tmp2 = sext i8 to i32 > ret i32 %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:

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

>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

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

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

...i32 %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? > > -Ch...