search for: lowerformalargu

Hi Robert, > I tried adding to the XCoreCallingConv.td: > CCIfByVal<CCPassByVal<0,4>> // pushes pointer to the stack This looks sensible to me. After that it comes down to cooperation between XCoreISelLowering's LowerFormalArguments and LowerCall functions. LowerFormalArguments is at the beginning of a function and is responsible for taking arguments out of registers and putting them into sensible places for the rest of the function to use. LowerCall is responsible for putting call arguments where callees will expect them...

Hi - help! I have read through previous threads on the subject of 'byval' e.g. https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which only pushed the pointer to the stack. However, I don't want to push the pointer to the sta...

Hello, The current code in PPCTargetLowering::LowerFormalArguments_SVR4 contains a FIXME over the code which saves the live floating-point registers to the stack. The FIXME states that this should only be done if CR bit 6 is set. I've been told that the lack of this check is preventing clang/LLVM from compiling a functional FreeBSD kernel on PPC. Is is p...

...; If I have a piece of bitcode looks like this: define i32 @_Z3fooii(i32 %a, i32 %b) #0 { %1 = add nsw i32 %a, %b ret i32 %1 } I want the assembly looks like this: move v0, p0 move v1, p1 add-int v10, v0, v1 return v10 So far, I have tried is to implement the LowerFormalArguments() like this: SDValue FOOTargetLowering::LowerFormalArguments( SDValue Chain, CallingConv::ID CallConv, bool isVarArg, const SmallVectorImpl<ISD::InputArg> &Ins, SDLoc dl, SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const { MachineFunction &MF...

I hate to be bothersome, but can someone please comment on this? Thanks again, Hal On Thu, 3 May 2012 14:49:04 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > Hello, > > The current code in PPCTargetLowering::LowerFormalArguments_SVR4 > contains a FIXME over the code which saves the live floating-point > registers to the stack. The FIXME states that this should only be done > if CR bit 6 is set. I've been told that the lack of this check is > preventing clang/LLVM from compiling a functional FreeBSD ker...

...anl.gov> wrote: > I hate to be bothersome, but can someone please comment on this? > > Thanks again, > Hal > > On Thu, 3 May 2012 14:49:04 -0500 > Hal Finkel <hfinkel at anl.gov> wrote: > >> Hello, >> >> The current code in PPCTargetLowering::LowerFormalArguments_SVR4 >> contains a FIXME over the code which saves the live floating-point >> registers to the stack. The FIXME states that this should only be done >> if CR bit 6 is set. I've been told that the lack of this check is >> preventing clang/LLVM from compiling a functi...

...ARegs:$dst), (ins BRegs:$src), "move $dst, $src", [(set i32:$dst, (MoveFlag i32:$src))]>; For example, I add this node into SDAG when I want to move the formal argument from the specific register class to other register class. I implement it in LowerFormalArguments() like this: .... for (auto &VA : ArgLocs) { if (VA.isRegLoc()) { // Arguments passed in registers EVT RegVT = VA.getLocVT(); VReg = RegInfo.createVirtualRegister(&FOO::BRegsRegClass); RegInfo.addLiveIn(VA.getLocReg(), VReg); SDValue ArgIn = DAG.ge...

Good to know, thanks! Currently I'm just not declaring an i8 register class since we only have load/store/convert available for that type. This works fine for most uses, but becomes a hassle when dealing with function parameters. For example, if the function argument is i8, the code in LowerFormalArguments sees it as an i16 since that is the next target legal type. For my target, we need to load function parameters from a special memory pool; so I need to emit any-extend loads of an 8-bit memory VT to a 16-bit register VT. But I don't see any way to get at the information that the function...

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>> which only pushed the pointer to the stack. Really, all it did was ask LowerCall and LowerFormalArguments to pass the pointer on the stack...

...but can someone please comment on this? > > > > Thanks again, > > Hal > > > > On Thu, 3 May 2012 14:49:04 -0500 > > Hal Finkel <hfinkel at anl.gov> wrote: > > > >> Hello, > >> > >> The current code in PPCTargetLowering::LowerFormalArguments_SVR4 > >> contains a FIXME over the code which saves the live floating-point > >> registers to the stack. The FIXME states that this should only be > >> done if CR bit 6 is set. I've been told that the lack of this > >> check is preventing clang/LLVM fro...

For my target, I handle incoming memory arguments by creating a store to memory (in LowerCall, [1]), then creating a fixed object on the stack and loading from it (in LowerFormalArguments[2]). This approach was based on MSP430. I now have the problem that the resulting loads in my output assembly are done assuming that the call stack looks something like: ------ MemArg ------ MemArg ------ <-- Frame Pointer This isn't true, because during prologue I emit a number of i...

Hi, I am new to LLVM. I am experimenting with a toy backend. I don't understand "LowerFormalArguments didn't return a valid chain" in SelectionDAGBuilder.cpp file. What is the interface here? What does it mean by returning a Chain? Thanks Jen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200...

...ry to access value of a.s in function recurse through gdb(i.e gdb > p a.s) it gives me an uninitialized value. The problem occurs only when we have a function call within function to which we have passed a structure. Could someone guide me were can i look to fix this issue. I have started with LowerFormalArguments in X86ISelLowering.cpp file. Thanks Karthik

...0; } llvm-gcc func.c -emit-llvm -c -O3 -o func.bc llc func.bc -relocation-model=static -march=mips -O0 -o func.s Command llc fails: llc:SelectionDAGBuilder.cpp:6440:void llvm::SelectionDAGISel::LowerArguments( llvm::BasicBlock):Assertion 'Invals.size() == Ins.size && "LowerFormalArguments didn't emit the correct number of values!"' failed Does the latest mips backend in svn trunk support variable arguments? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100203/875d...

...tly I'm just not declaring an i8 register class since we only have > > load/store/convert available for that type. This works fine for most > uses, > > but becomes a hassle when dealing with function parameters. For example, > > if the function argument is i8, the code in LowerFormalArguments sees it > as > > an i16 since that is the next target legal type. For my target, we need > to > > load function parameters from a special memory pool; so I need to emit > > any-extend loads of an 8-bit memory VT to a 16-bit register VT. But I > > don't see a...

...ning of arguments, a 32 bit value is passed in r22, r23, r24, r25 (the registers are 8 bit). And two 16 bit values would be passed, argument 1 in r24, r25 and argument 2 in r22, r23. When I'm looking in the function lowering code in SelectionDAGISel::LowerArguments and AVRTargetLowering::LowerFormalArguments, we already have a problem because the 32 bit return value has been turned into two 16 bit values by the legaliser and the information has been lost that it was one 32 bit value. So the lowering code cannot correctly lower the return value and gets the two 16 bit words mixed up. Which bi...

...areas of attention will be SelectionDAGISel::LowerArguments SelectionDAGLowering::LowerCallTo SelectionDAGLowering::visitRet These functions are responsible for breaking up LLVM IR values into register-sized pieces and handing them off to target-specific code through these virtual functions: TLI.LowerFormalArguments TLI.LowerCall TLI.LowerReturn (Actually, SelectionDAGLowering::LowerCallTo calls TargetLowering::LowerCallTo, which calls TargetLowering::LowerCall, for historical reasons.) Basically, the task here is to interpose code which will recognize when an automatic sret is needed, set up a static a...

> 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? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

...s! > > Currently I'm just not declaring an i8 register class since we only have > load/store/convert available for that type. This works fine for most uses, > but becomes a hassle when dealing with function parameters. For example, > if the function argument is i8, the code in LowerFormalArguments sees it as > an i16 since that is the next target legal type. For my target, we need to > load function parameters from a special memory pool; so I need to emit > any-extend loads of an 8-bit memory VT to a 16-bit register VT. But I > don't see any way to get at the informati...