search for: callloweringinfo

...lower call). > > So it seems possible to add an additional parameter to LowerCallTo and pass > it down the chain > until Mips lower call is invoked. > > Is this more or less what you had in mind? That's the right idea... but as far as I can tell, it's already part of the CallLoweringInfo structure. -Eli

On 01/08/2013 01:48 PM, Eli Friedman wrote: > On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >> For example: >> >> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >> -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float > Try something like the following: > > float f; > double test(void*

...lectionDAG/SelectionDAGBuilder.cpp b/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp index a8db35c..29353a6 100644 --- a/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp +++ b/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp @@ -5726,7 +5726,7 @@ SelectionDAGBuilder::lowerInvokable(TargetLowering::CallLoweringInfo &CLI, } void SelectionDAGBuilder::LowerCallTo(ImmutableCallSite CS, SDValue Callee, - bool isTailCall, + bool isTailCall, bool isVarArg, MachineBasicBlock *LandingPad) { Point...

...t this *will* break your build. Please see any in-tree target for the new interface and how to access the values that used to be available as individual function parameters. As a quick example, the ARM implementation for LowerCall is now: SDValue ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI, SmallVectorImpl<SDValue> &InVals) const { SelectionDAG &DAG = CLI.DAG; DebugLoc &dl = CLI.DL; SmallVector<ISD::OutputArg, 32> &Outs = CLI.Outs; SmallVector<SDValue, 32>...

...: > Any change outside of statepoint lowering is highly suspect. Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying) has exactly one other caller: visitCall, which doesn't match vararg functions. Every other codepath directly calls TargetLowering::LowerCallTo, supplying CallLoweringInfo information explicity (it's a structure with a vararg field). I suspect I'm not overloading SelectionDAGBuilder enough. > I'm pretty sure that calling a vararg function through a statepoint already > works without code change (other than the verifier). (Or at least simple >...

In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this struct, and this struct is the means for passing information to/from each target's LowerCall method. Right now, the interface is a bit rough around the edges, but I wanted to get f...

...ki at nvidia.com> wrote: > In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this struct, and this struct is the means for passing information to/from each target's LowerCall method. Right now, the interface is a bit rough around the edges, but I wanted to get f...

On Apr 19, 2012, at 12:46 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > >> >> From: Evan Cheng [mailto:evan.cheng at apple.com] >> Sent: Thursday, April 19, 2012 10:47 AM >> To: Justin Holewinski >> Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover >> Subject:

...e: > > > In response to this discussion, I've prepared the attached patch as an initial > prototype for the LowerCall/LowerCallTo change. All of the information > currently needed by the back-ends, and the extra information needed by > the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The > various SelectionDAG classes have been modified so any calls to > TargetLowering::LowerCallTo use this struct, and this struct is the means for > passing information to/from each target's LowerCall method. Right now, the > interface is a bit rough around the edges, b...

...Ty); + ID = StructTypes.size(); + } + } + } + + Res = DAG.getConstant(ID, getCurSDLoc(), MVT::i32); + setValue(&CI, Res); +} + /// Returns an AttributeSet representing the attributes applied to the return /// value of the given call. static AttributeSet getReturnAttrs(TargetLowering::CallLoweringInfo &CLI) { diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h b/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h index f71190d..f037689 100644 --- a/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h +++ b/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h @@ -855,6 +855,7 @@ private: void visit...

On 2015/8/12 12:57, Alexei Starovoitov wrote: > On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote: >> Think about a program like this: >> >> struct strA { int a; } >> struct strB { int b; } >> int func() { >> struct strA a; >> struct strB b; >> >> a.a = 1; >> b.b = 2; >>

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,