similar to: [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

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 {

> On further reflection, I actually like the idea of adding 4 attributes > better than adding knowledge of "int" into TargetData. "int" is a C > notion that doesn't really belong in TargetData, and it is better for > the optimizers to have the front-end expose the implicit promotions. This is very true and indeed applicable to this problem... So I have to

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

On Jun 4, 2008, at 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 >>>

On May 20, 2008, at 2:16 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: > >> 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". Ok. > What I don't understand is I >

Any thoughts on this? I would like to get it right before jumping into the nuts and bolts of it.... Thanks ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.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.

On Jun 5, 2008, at 11:33 PM, Evan Cheng wrote: > On Jun 4, 2008, at 11:12 AM, Chris 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,

Some targets want to do the promotion in the callee and some in the caller. Now what you are discussing in your bug is we shouldn't do in both... Now the tricky part is that many targets (not for the sake of promotion, but for the sake of performance) return a smaller value in a larger register (say if the function is to return char, they return it in 32 bit register); So they are effectively

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

>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

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 >

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.... We had long discussions about this last year, and this is what has been decided.

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:

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

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

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

Chris, I see, so in deed the front-end sets the attributes on the declaration of the called function; which in theory is also available to the caller through the CALL node. Now here is what I think: I agree that 4 attributes are a bit ugly. I think we can only get away with 2 attributes to signify sign extension or zero extension. Currently the front end does not promote the function declaration;

Chris, I did not quite understand the "The bad thing about ..." part of your argument. I'm not sure which of the two scenarios are you comparing (promoting in FrontEnd vs BackEnd) or (promotion to int vs i32) Regardless, I agree with you and shap that promotions should take place in the FrontEnd and this is my reason: The standard allows calling a function without prototype and

Chris, Regardless of the optimization problem that we had discussions before, I think we all agreed that promotion of return value should take place in the front-end... Now I have a suggestion: In the message below you laid out the suggested IR for "char foo()" when its return value is promoted to i32 in front-end. You have applied the promotion both at the definition of function and