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

There is a FIXME part in SelectionDAGLowering::visitRet() that is giving us trouble. And I would like to know how the community has planned for addressing this problem. The current implementation assumes that all C calling conventions require the return value of integer types in the largest register class (for most ports 32-bit). However, this is not the case for our port. We have two register

I know that many ABIs require this for performance purpose, but I haven't seen anything in the standard that suggests promotion of return value to integer. Furthermore, I think the LLVM is supposed to be independent of language. So I'm not sure if SelectionDAGLowering is the right place for this promotion to begin with, TargetLowering class seems more logical; but I'm not sure how.

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

But they both follow the same calling convention. There are two possibilities in the caller: 1) Call node returns sizeof(int) or larger: in this case there is no truncation. 2) Call node returns smaller than sizeof(int): in this case callee always has to return an int so it has to consistently either sign extend or zero extend because int is either signed or unsigned consistently for that port.

I just took a closer read of Chris' "LLVM Exception Handling Changes" document and have some comments. [...] > This bloats the code and is quite slow: it's not feasible to use > hardware traps to implement these checks. It's not totally infeasible. An approach similar to what if-conversion does could implement this. I'm not necessarily advocating this, I'm

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

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. Ali ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alireza.Moshtaghi at microchip.com

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

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

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

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

I think the "answer" is yes. Given the attributes are a bitfield, it would be difficult to encode any arbitrary type. I am happy with just adding sign_ext_from_i1 and zero_ext_from_i1 for now. That's progress! :-) Evan On Jun 9, 2008, at 12:43 PM, Alireza.Moshtaghi at microchip.com wrote: > >> >> Yes, this would be much nicer. The only issue is that

On May 27, 2008, at 3:33 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: > 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. Right. > Now here is what I think: > I agree that 4 attributes are

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

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