Alireza.Moshtaghi at microchip.com
2009-Mar-31 18:46 UTC
[LLVMdev] promotion of return value.
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. 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_i16Aren'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. ________________________________ From: llvmdev-bounces at cs.uiuc.edu on behalf of Alireza.Moshtaghi at microchip.com Sent: Wed 3/4/2009 11:41 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] promotion of return value. Below I have pasted the latest design that we discussed... Now we would like to pick it up and do the implementation. 1) Is there any last change that we would like to add? 2) Has anyone been working on it? I haven't seen any thing new in the code so I assume the answer is no... Thanks Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology Subject: Troubling promotion of return value to Integer ... On May 29, 2008, at 10:30 AM, <Alireza.Moshtaghi at ...> <Alireza.Moshtaghi at ... > wrote:> Let me summarize what we discussed so far: > > 1) The return value promotion will be removed from llvm backend and > implemented in both front-ends (clang and llvm-gcc) > > 2) The promotions are only applied to the return value in the body > of the function. > Return value of function definition and declaration will not be > promoted > > Example for a Target with 32-bit int type: > > char foo() { > char c = ... > return c; > } > > Is translated to: > > define i8 @foo() { > ... > %tmp = sext i8 ... to i32 > ret i32 %tmp > }Close. The return value of declarations also has to be promoted. foo should be translated to: define i32 @foo() sign_ext_from_i8 { ... %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.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 defined)They also go on the function definition, as above.> Am I capturing everything?Yep! The place to start with this is introducing the new attributes. Given the new attributes, we can mock up .ll code that uses them and improve the optimizers to use them. When everything there is correct, we can move each front-end over to start using them. -Chris _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090331/9c1b306c/attachment.html>
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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090331/0eff1a30/attachment.html>
> Did you see this Ali? > http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txtWould you mind adding it to SVN? Would make it easier to comment on. In particular, it would be nice to add examples for X86 (caller extends. High bits undefined in the callee) and PPC (callee extends). And I still don't understand why in short y(); int z() { return ((int)y() << 16) >> 16; } we can remove the sign extension on x86 (I really think we cannot).> -ChrisThanks, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Alireza.Moshtaghi at microchip.com
2009-Apr-01 04:50 UTC
[LLVMdev] promotion of return value.
Chris, Thanks for the note. I think it captures what we discussed before, except that you have not explicitly detailed the 4 (or in the case of 64-bit architectures, 8) attributes:> sign_ext_from_i8, sign_ext_from_i16 > zero_ext_from_i8, zero_ext_from_i16Could you please add that stuff to your proposal as well? Defining the textual syntax of how these attrs would be used will eliminate many ambiguities in the discussion. Thanks Ali. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, March 31, 2009 11:55 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] promotion of return value. 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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090331/4e99b0fe/attachment.html>