similar to: [LLVMdev] Integer promotion of return node operand

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

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

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

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.

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

On Wed, Mar 16, 2011 at 12:35 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > >> Promoting the return value is unsafe for bool returns on x86-64, which >> in the latest revision of the ABI only guarantees that the top 7 bits of >> the 8-bit register are 0. > > My comment is a bit off, because the question

On May 16, 2008, at 11:12 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: > > 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) Assume we make the change I

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

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

Has any one been successful with a 16-bit target? I'm new to LLVM and am having problems. One problem I found stems from code in lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: visitRet(): // If this is an integer return value, we need to promote it ourselves to // the full width of a register, since getCopyToParts and Legalize will use // ANY_EXTEND rather than sign/zero. // FIXME:

> 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

Background: The Cell SPU does not have condition registers in the normal sense. It fits the "zero or negative one" model, preferably with an i32 register, which is what getSetCCResultType() will return. Problem: LegalizeTypes promotes i1 to i8 via an i32 setcc, i.e., the generated type legalization is: (i8:truncate (i32:setcc i32:lhs, i32:rhs, ch:cond)) How do I keep

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 {

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

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

Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken

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,