Alireza.Moshtaghi at microchip.com
2009-Mar-04 18:41 UTC
[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
On Mar 4, 2009, at 10:41 AM, Alireza.Moshtaghi at microchip.com wrote:> 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...Great! I think that this is still the best plan, thanks for tackling it! -Chris> > > 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
Alireza.Moshtaghi at microchip.com
2009-Mar-12 17:38 UTC
[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 -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6877 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/0ed3616f/attachment.bin>
>> 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 >> promotedYou might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779. If I understand what you are proposing, it is exactly the opposite of what gcc does, which would be annoying for someone trying to link gcc and llvm compiled code. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
On Thursday 12 March 2009 18:38:33 Alireza.Moshtaghi at microchip.com wrote:> 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?Since the LLVM IR supports arbitrary precision integers, shouldn't there be zero_ext_from_i17 as well? At least zero_ext_from_i1? Ciao, Duncan. PS: What is the problem this is trying to solve?
>> 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) >I am a bit lost, but if we are going to do what gcc does (only extent in the caller) I don't thin we need this. We can compile char foo() { char c = ... return c; } into define i8 @foo() { ... %tmp = .... ret i8 %tmp } and if a caller wants a 32 bit value it can extend it according to the c/c++ prototype of the function. In theory I think we could also do this for passing arguments to functions, but I am not sure how this would interact with existing code compiled with gcc. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Rafael Espindola wrote:>>> 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 > > You might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779. > > If I understand what you are proposing, it is exactly the opposite of > what gcc does, which would be annoying for someone trying to link gcc > and llvm compiled code.That's right. In gcc we used to do this in the front-ends but we stopped. This required quite a lot of discussion with the Linux ABI standardization people. Andrew.
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>