search for: lowerret

...for arguments. Create a TAILCALL node (a pseudo instruction) holding the Callee (Register or TargetGlobalAddress/ExternalSymbol), the stack adjustment as a constant, and the live-in registers. The TargetLowering class has a IsLastCallTailCall state field which is set to true such that the LowerRET function nows it has to produce different code. The TAILCALL node is then returned. If it is not okay the code produces a function call like the std calling convention (callee pops arguments on return). There is one difference though: since tail call functions might arbitrarily change stack...

...> Create a TAILCALL node (a pseudo instruction) holding the Callee > (Register or TargetGlobalAddress/ExternalSymbol), the stack > adjustment as a constant, and the live-in registers. The > TargetLowering class has a IsLastCallTailCall state field which is > set to true such that the LowerRET function nows it has to produce > different code. The TAILCALL node is then returned. > > If it is not okay the code produces a function call like the std > calling convention (callee pops arguments on return). > There is one difference though: since tail call functions might > ar...

Hello, Arnold. Only quick comments, I'll try to make a full review a little bit later. > 0.)a fast calling convention (maybe use the current > CallingConv::Fast, or create a CallingConv::TailCall) > 1.) lowering of formal arguments > like for example x86_LowerCCCArguments in stdcall mode > we need to make sure that later mentioned CALL_CLOBBERED_REG is >

everyone-- My build of LLVM-GCC from top-of-trunk sources is failing with the assertion in ARMISelTargetLowering at line 667, in LowerRET, where it says "Do not know how to return this many arguments!" This happens when the cross-compiler attempts to build _muldc3 for libgcc2. The more I have investigated this problem, them more convinced I have become that this isn't a stupid newbie bug, but something more tr...

I have started to add support for FP in the ARM backend. According to the ABI, 32 bit floating point numbers should be returned in R0 and 64bit ones in R0/R1. I have solved the 32 bit case by inserting bit_converts in LowerRET. For the 64bit case I considered two options: 1) Creating two nodes. fp_lo and fp_hi. I could then select fmrdh and fmrdl with (set IntRegs:$dst (bitconvert (fp_hi DFPRegs:$src))) and (set IntRegs:$dst (bitconvert (fp_lo DFPRegs:$src))) 2) Create a node similar to copytoreg that has two results....

On Apr 30, 2008, at 11:19 PM, james woodyatt wrote: >> $TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not >> fixed up You need to run the compile with -save-temps and then look at the .s file. If you like it, it is an assembler bug. If you don't like it, it is a bug in the compiler. If you don't know if you like it, as your assembler vendor (binutils)

...on, 2 Oct 2006, [UTF-8] Rafael Esp?ndola wrote: > I have started to add support for FP in the ARM backend. cool. > According to the ABI, 32 bit floating point numbers should be returned > in R0 and 64bit ones in R0/R1. Ok. > I have solved the 32 bit case by inserting bit_converts in LowerRET. Yep. > For the 64bit case I considered two options: > > 1) Creating two nodes. fp_lo and fp_hi. I could then select fmrdh and fmrdl with > (set IntRegs:$dst (bitconvert (fp_hi DFPRegs:$src))) and > (set IntRegs:$dst (bitconvert (fp_lo DFPRegs:$src))) Alternatively, you could merg...

...il call optimization code for X86. It mostly does what i have described in preceeding emails: There is new code for lowering fastcc calls: LowerX86_32FastCCCallTo LowerX86_32FastCCArguments There is some code checking whether a TAIL CALL really is eligible for tail call optimization. I modified: LowerRET to create a TC_RETURN node. (used for adjusting stackpointer and jumping to function in epilogue, similar to EH_RETURN) There is a new calling convention: CC_X86_32_TailCall which is ~ CC_X86_32_C minus ECX. There are some modifications in X86InstrInfo.td There are new X86 DAG nodes: TRUETAILCA...

...motion both at the definition of function and its return statement. This leaves no way for backend to differentiate "char foo()" from "int foo()". Currently in llvm, promotion affects only the return value but function definition is not promoted, and that is helpful because in LowerRET() I can look at the return size from the function definition and differentiate a promoted return statement from a non-promoted one and accordingly do the desired lowering for my port. I would like to suggest that when the promotion is done in the Front-end, we do the same and only promote the retu...

everyone-- I'm trying to build LLVM-GCC as a cross-compiler for a new target. I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something

...n LowerCALL and it is this one that fails. When I get the arguments to the function call, (SDValue Arg = TheCall->getArg(i);), the returned SDValue is a FrameIndex, and I don't handle the case correctly. The only issue that I have is that none of the other backends have any code in LowerCALL/LowerRET/LowerFORMAL_ARGUMENTS that explicitly handle FrameIndexSDNode's as arguments. This leads me to believe that I shouldn't have to handle this case and there is an error occurring somewhere else and is showing up here. My test case is fairly simple: float func(float *a); void test(float *pos...

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

...at i have described in preceeding > emails: > > There is new code for lowering fastcc calls: > LowerX86_32FastCCCallTo > LowerX86_32FastCCArguments > > There is some code checking whether a TAIL CALL really is > eligible for tail call optimization. > > I modified: > LowerRET > to create a TC_RETURN node. (used for adjusting stackpointer and > jumping to function in epilogue, similar to EH_RETURN) > > There is a new calling convention: > CC_X86_32_TailCall > which is ~ CC_X86_32_C minus ECX. > > There are some modifications in > X86InstrInfo....

On Jan 27, 2009, at 3:54 PM, Villmow, Micah wrote: > Ok, I've had time to track this down a little bit more and I seem to > have found another case where it fails. This is occurring during > Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem > seems > to be that somehow the CopyToReg part of the switch statement in > ScheduleDAG::EmitNode has a

Ok, I've had time to track this down a little bit more and I seem to have found another case where it fails. This is occurring during Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem seems to be that somehow the CopyToReg part of the switch statement in ScheduleDAG::EmitNode has a FrameIndex as its second operand. This is especially problematic because the code is either