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)

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

On Thu, 2008-05-15 at 09:48 -0700, Alireza.Moshtaghi at microchip.com wrote: > 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.... I can answer the ABI vs. language part of this question. On modern

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

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

On May 12, 2008, at 8:21 AM, Sachin.Punyani at microchip.com wrote: > > When LLVM constructs the DAG for above case - it tries to promote > (during DAG construction phase - before any combine or legalize phase) > the return node operand to i32. > > I have few doubts here: > 1) If C language requires integer promotion of return value argument > then should it not be done by

Hi All, Please consider the following case Test case -- -------------------------------------- char a; void fun () { return a; } -------------------------------------- Following disassembly (using llvm-dis) is generated for the above test case -------------------------------------- ; ModuleID = 'first.bc' @a = internal global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry:

Hi I am sorry. In my previous mail I mistyped the test case and disassembly. Test case -- -------------------------------------- char a; char fun () { return a; } -------------------------------------- Disassembly -------------------------------------- ; ModuleID = 'first.bc' @a = global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry: %tmp = load i8* @a ; <i8>

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

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

On May 15, 2008, at 12:14 PM, Duncan Sands wrote: > 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,

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

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

On May 16, 2008, at 4:07 PM, <Alireza.Moshtaghi at microchip.com> wrote: > To me, this “optimization” problem doesn’t seem to be a consequence > of doing the promotion differently than what is currently being done > in llvm. > Anyways, I don’t agree that the information is completely lost. > Shouldn’t an llvm pass be able to figure out if the truncated value > is

Going that route, and with 64 bit processors picking up, I'm sure soon we will have to add two more new attributes: sign_ext_from_i32 and zero_ext_from_i32 which makes the number of attributes 8 (i1,i8,i16,i32) rather than 4 (i8,i16) Is this exactly what is desired? From one perspective it is good because it doesn't require too much modification. On the other hand the way that attributes

To me, this "optimization" problem doesn't seem to be a consequence of doing the promotion differently than what is currently being done in llvm. Anyways, I don't agree that the information is completely lost. Shouldn't an llvm pass be able to figure out if the truncated value is coming from a function call, and since it is aware of calling convention, it should be able to

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.

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