Alireza.Moshtaghi at microchip.com
2008-May-14 17:43 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
In this thread I'm trying to merge two email threads into one, because both discuss the same problem that's troubling us and I would like to reach a conclusion on what would be the best approach. To minimize the size of this thread I only mention the subject of the other two threads: (1) [LLVMdev] Integer promotion of return node operand (initiated by Sachin) (2) [LLVMdev] trouble with 32-bit promotion of return value (initiated by myself) To summarize: Evan has replied to thread (1) and suggested to add a calling convention and check for it in visitRet Dan replied to thread (2) and suggested to add a new field to the TargetLowering class, and then let each target specify the minimum integer type to promote return types to Either way, I think we all agree that the root of the problem is the FIXME in SelectionDAGLowering::visitRet() But what is the preferred method? Thanks Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080514/32e4e5d1/attachment.html>
Duncan Sands
2008-May-15 08:25 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
> Either way, I think we all agree that the root of the problem is the > FIXME in SelectionDAGLowering::visitRet()What I would like to know is if the promotion of return values to integer is specified by the C language standard, or if it is specified by the (target specific) ABI. Ciao, Duncan.
Evan Cheng
2008-May-15 18:11 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote:> In this thread I’m trying to merge two email threads into one, > because both discuss the same problem that’s troubling us and I > would like to reach a conclusion on what would be the best approach. > To minimize the size of this thread I only mention the subject of > the other two threads: > (1) [LLVMdev] Integer promotion of return node operand > (initiated by Sachin) > (2) [LLVMdev] trouble with 32-bit promotion of return value > (initiated by myself) > > To summarize: > Evan has replied to thread (1) and suggested to add a calling > convention and check for it in visitRet > Dan replied to thread (2) and suggested to add a new field to the > TargetLowering class, and then let each target specify the minimum > integer type to promote return types to > > Either way, I think we all agree that the root of the problem is the > FIXME in SelectionDAGLowering::visitRet() > > But what is the preferred method?Both. :-) If you are using a non-C ABI, then you may not need to do the promotion at all. However, if you do need to do the promotion, you need to know the type of "int". It's not entirely clear to me what is the best way to accomplish. To me, I don't think TargetLowering is the right place to add the hook. How about TargetData.h ? There is a getIntPtrType(), perhaps we need a getIntType()? Evan> > Thanks > Ali > _______________________________________________ > 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/20080515/58d8b356/attachment.html>
Alireza.Moshtaghi at microchip.com
2008-May-15 19:10 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
>If you are using a non-C ABI, then you may not need to do the promotionat all. However, if you do need to do the .... Our port is for C language, however, on an 8-bit platform priorities shift a little bit. Really the natural size of int must be 8 bit, however, 8 bit is too small for most calculations so we have to choose 16, but there is no 16-bit register available. And that is where the whole problem starts because promoting the return of char to int becomes too expensive; so we don't want to do it. Being able to turn the promotion off is going to solve our problem, but currently there is no hook for that in target specific classes. Ali. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Thursday, May 15, 2008 11:11 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Troubling promotion of return value to Integer ... On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote: In this thread I'm trying to merge two email threads into one, because both discuss the same problem that's troubling us and I would like to reach a conclusion on what would be the best approach. To minimize the size of this thread I only mention the subject of the other two threads: (1) [LLVMdev] Integer promotion of return node operand (initiated by Sachin) (2) [LLVMdev] trouble with 32-bit promotion of return value (initiated by myself) To summarize: Evan has replied to thread (1) and suggested to add a calling convention and check for it in visitRet Dan replied to thread (2) and suggested to add a new field to the TargetLowering class, and then let each target specify the minimum integer type to promote return types to Either way, I think we all agree that the root of the problem is the FIXME in SelectionDAGLowering::visitRet() But what is the preferred method? Both. :-) If you are using a non-C ABI, then you may not need to do the promotion at all. However, if you do need to do the promotion, you need to know the type of "int". It's not entirely clear to me what is the best way to accomplish. To me, I don't think TargetLowering is the right place to add the hook. How about TargetData.h ? There is a getIntPtrType(), perhaps we need a getIntType()? Evan Thanks Ali _______________________________________________ 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/20080515/e443bf31/attachment.html>
Duncan Sands
2008-May-15 19:14 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
Hi Evan,> If you are using a non-C ABI, then you may not need to do the > promotion at all. However, if you do need to do the promotion, you > need to know the type of "int".how does this work for parameters. Suppose I have an i1 parameter. The AMD64 ABI says it is passed in one of %rsi, %rdx, %rcx, %r8 and %r9 registers. In the case of _Bool (i1) it says that the upper 63 bits will be zero. How does this work? I thought i1 would be legalized to i8 (which is legal, right?). Due to being marked zext, the upper 7 bits of the i8 will be zero. But where does it get extended to an i64 with upper 63 bits zero? Thanks, Duncan.
Chris Lattner
2008-May-16 13:11 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
On May 14, 2008, at 10:43 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote:> In this thread I’m trying to merge two email threads into one, > because both discuss the same problem that’s troubling us and I > would like to reach a conclusion on what would be the best approach. > To minimize the size of this thread I only mention the subject of > the other two threads: > (1) [LLVMdev] Integer promotion of return node operand > (initiated by Sachin) > (2) [LLVMdev] trouble with 32-bit promotion of return value > (initiated by myself) > > To summarize: > Evan has replied to thread (1) and suggested to add a calling > convention and check for it in visitRet > Dan replied to thread (2) and suggested to add a new field to the > TargetLowering class, and then let each target specify the minimum > integer type to promote return types to > > Either way, I think we all agree that the root of the problem is the > FIXME in SelectionDAGLowering::visitRet()Hi Ali, I think there are two sides to this issue. The ultimate problem is that the code generator has a builtin assumption that sizeof(int) = 32 bits. IIRC, this comes into play in two places: 1. Arguments to calls are known to be sign/zero extended to int in certain cases. 2. The return value of functions is implicitly promoted. Lets talk about #2 first, because it is the simplest case. Here the front-end types the function as (f.e.) returning i8, and then has the code generator insert the extension to (for example) i32. The attribute on the function tells the code generator whether to sign or zero extend it. To me, the solution to this is to have the C front-end insert an explicit extension of the appropriate type to the right size. This would mean that the code generator would now never insert the extension. Since the C front-end knows the size of int, on your target, you could have it extend to 16 or 8 bits, as appropriate. This is also good, because the extension is exposed to the mid-level optimizer, allowing it to be eliminated more aggressively. The bad thing about doing this is that, on the caller side, we lose information. With the current approach, the caller knows that the value is (for example) 8 bits but sign or zero extended as appropriate. This allows the caller side to do optimizations based on this fact. If all return values were i32, we wouldn't know that the top 24 bits were sign/zero extended. I think we can handle this by adding some new attributes, but this is marginally ugly. What do you think? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080516/55129aab/attachment.html>
Jonathan S. Shapiro
2008-May-16 15:45 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
On Fri, 2008-05-16 at 06:11 -0700, Chris Lattner wrote:> To me, the solution to this is to have the C front-end insert an > explicit extension of the appropriate type to the right size.Opinion: The front end should be responsible for introducing all necessary promotions, sign extensions, or zero extensions. The absence of these operations where required is a type error in the emitted IR, and should be treated as such. The job of the back end is to reject ill-typed input as malformed, not correct it. Therefore, the code generator should not be inserting these promotions. As a matter of implementation, an explicitly run decorating IR pass might be a fine implementation that avoids invasive changes in current front ends.> If all return values were i32, we wouldn't know that the top 24 bits > were sign/zero extended. I think we can handle this by adding some > new attributes, but this is marginally ugly.The real issue here is that there is a divergence between the logical type and the representation type, the back end needs to know both for different purposes, and within the constraints of the current IR (absent new annotations) information about one or the other is lost. Is this a more general issue, or are annotations sufficient? shap
Alireza.Moshtaghi at microchip.com
2008-May-16 18:12 UTC
[LLVMdev] Troubling promotion of return value to Integer ...
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 assumes "int" return value; and I realize that this is the primary reason why the return value is being promoted. This ties this promotion to int type and not the size of any register in target, which in turn makes it a language issue rather than code generation issue; hence FrontEnd must take care of it. Now for our port, things are different. In most (sane) ports, the target provides an integer class for int... however, things are different in our (insane) port. We only have an 8-bit data bus but we also want 16-bit int type. So this promotion will make char return values (which are used heavily in many application in 8-bit environment) quite inefficient. So we need a way to turn off this promotion all together and deal with default function prototype in a different way (perhaps issue a diagnostic ...) Cheers Ali>The bad thing about doing this is that, on the caller side, we loseinformation. With the current approach, the caller knows that the value is (for example) 8 >bits but sign or zero extended as appropriate. This allows the caller side to do optimizations based on this fact. If all return values were i32, we wouldn't >know that the top 24 bits were sign/zero extended. I think we can handle this by adding some new attributes, but this is marginally ugly.>>What do you think?>>-Chris-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080516/6df42317/attachment.html>
Apparently Analagous Threads
- [LLVMdev] Troubling promotion of return value to Integer ...
- [LLVMdev] trouble with 32-bit promotion of return value
- [LLVMdev] Troubling promotion of return value to Integer ...
- [LLVMdev] Troubling promotion of return value to Integer ...
- [LLVMdev] Troubling promotion of return value to Integer ...