search for: lowercallto

...d may be solved by the first. If the LowerCall() arguments are encapsulated within some descriptor object, then extensions to this descriptor class would be transparent to existing targets, both in-tree and out-of-tree (assuming the API is consistent). What is the overall plan for LowerCall() and LowerCallTo()? I noticed the comment on LowerCallTo() that implies it should be merged into SelectionDAGISel when all targets are using LowerCall (which I believe they are)? > > I believe Dan has some thoughts in this topic. That FIXME comment about LowerCallTo is probably an anachronism, and no longe...

...an email to llvmdev to warn owners of all the out-of-tree targets about the ABI change. Evan On May 15, 2012, at 6:56 AM, Justin Holewinski <jholewinski 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 i...

Philip Reames wrote: > 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 overloa...

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

...and convert all the targets first. > Also, please don't forget to send an email to llvmdev to warn owners of all > the out-of-tree targets about the ABI change. Of course! :) So, are people okay with the interface? This is basically just struct-ifying the parameters to TargetLowering::LowerCallTo/LowerCall. My main concerns are the handling of the InVals and IsTailCall variables. I left InVals as a separate parameter to LowerCall, since it is entirely produced by the implementation. IsTailCall remains in the struct since it is given a value before LowerCall, although the LowerCall implem...

...d may be solved by the first. If the LowerCall() arguments are encapsulated within some descriptor object, then extensions to this descriptor class would be transparent to existing targets, both in-tree and out-of-tree (assuming the API is consistent). What is the overall plan for LowerCall() and LowerCallTo()? I noticed the comment on LowerCallTo() that implies it should be merged into SelectionDAGISel when all targets are using LowerCall (which I believe they are)? Evan On Apr 19, 2012, at 8:07 AM, Justin Holewinski <jholewinski at nvidia.com<mailto:jholewinski at nvidia.com>> wrote:...

...etLowering.h > =================================================================== > --- include/llvm/Target/TargetLowering.h (revision 42247) > +++ include/llvm/Target/TargetLowering.h (working copy) > @@ -851,8 +851,18 @@ > virtual std::pair<SDOperand, SDOperand> > LowerCallTo(SDOperand Chain, const Type *RetTy, bool > RetTyIsSigned, > bool isVarArg, unsigned CallingConv, bool isTailCall, > - SDOperand Callee, ArgListTy &Args, SelectionDAG &DAG); > + bool isNextInstRet, SDOperand Callee, ArgListTy &Args,...

All, The attached patch adds two extra arguments to TargetLowering::LowerCall: RetTy and Args. These arguments are used in TargetLowering::LowerCallTo() to construct the Ins and OutVals parameters, but are not available to the target via LowerCall(). Some targets require this additional information, and the LowerCallTo() method is not virtual in TargetLowering. Instead of making that method virtual, this patch adds the extra arguments so targe...

...d may be solved by the first. If the LowerCall() arguments are encapsulated within some descriptor object, then extensions to this descriptor class would be transparent to existing targets, both in-tree and out-of-tree (assuming the API is consistent). What is the overall plan for LowerCall() and LowerCallTo()? I noticed the comment on LowerCallTo() that implies it should be merged into SelectionDAGISel when all targets are using LowerCall (which I believe they are)? I believe Dan has some thoughts in this topic. Evan > > Evan > > On Apr 19, 2012, at 8:07 AM, Justin Holewinski <j...

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating t...

...=================================================================== >> --- include/llvm/Target/TargetLowering.h (revision 42247) >> +++ include/llvm/Target/TargetLowering.h (working copy) >> @@ -851,8 +851,18 @@ >> virtual std::pair<SDOperand, SDOperand> >> LowerCallTo(SDOperand Chain, const Type *RetTy, bool >> RetTyIsSigned, >> bool isVarArg, unsigned CallingConv, bool isTailCall, >> - SDOperand Callee, ArgListTy &Args, SelectionDAG &DAG); >> + bool isNextInstRet, SDOperand Callee, ArgList...

...t;- %a r2,r3 <- %b Darwin: r0 <- %a r1,r2 <- %b void @g(i32 %a, i32 %b, i32 %c) ARM EABI or Darwin: r0 <- %a r1 <- %b r2 <- %c The problem is: I can't differ a i64 argument of two i32 arguments in ISD::CALL (ARM doesn't have i64 registers). The function TargetLowering::LowerCallTo transforms all i64 arguments in two i32 arguments. A possible solution is override TargetLowering::LowerCallTo and do not expand i64 arguments. I don't know if it's a good solution. None backend overrides this function. Any ideas? Lauro

...argets. Anyone wants to take the lead on this? Evan On Apr 19, 2012, at 8:07 AM, Justin Holewinski <jholewinski at nvidia.com> wrote: > All, > > The attached patch adds two extra arguments to TargetLowering::LowerCall: RetTy and Args. These arguments are used in TargetLowering::LowerCallTo() to construct the Ins and OutVals parameters, but are not available to the target via LowerCall(). Some targets require this additional information, and the LowerCallTo() method is not virtual in TargetLowering. Instead of making that method virtual, this patch adds the extra arguments so targe...

Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to legalize MVT::f64 arguments that have been pre-p...

...AG/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) { PointerType *PT = cast<PointerType>(CS.getCalledValue...

...ndex: include/llvm/Target/TargetLowering.h =================================================================== --- include/llvm/Target/TargetLowering.h (revision 42247) +++ include/llvm/Target/TargetLowering.h (working copy) @@ -851,8 +851,18 @@ virtual std::pair<SDOperand, SDOperand> LowerCallTo(SDOperand Chain, const Type *RetTy, bool RetTyIsSigned, bool isVarArg, unsigned CallingConv, bool isTailCall, - SDOperand Callee, ArgListTy &Args, SelectionDAG &DAG); + bool isNextInstRet, SDOperand Callee, ArgListTy &Args, + Select...

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

...owner for their opinions. Nemanja On Thu, Jan 3, 2019 at 4:54 PM Justin Hibbits <jrh29 at alumni.cwru.edu<mailto:jrh29 at alumni.cwru.edu>> wrote: Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to legalize MVT::f64 arguments that have been pre-p...

...translated into the special-purpose instruction-selection IR, which is lower-level. Calls are split up into multiple parts which are eventually lowered into the actual instructions for the calling sequence. The main 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::LowerCall...

...;- %b > > void @g(i32 %a, i32 %b, i32 %c) > > ARM EABI or Darwin: > r0 <- %a > r1 <- %b > r2 <- %c > > The problem is: I can't differ a i64 argument of two i32 arguments in > ISD::CALL (ARM doesn't have i64 registers). The function > TargetLowering::LowerCallTo transforms all i64 arguments in two i32 > arguments. > > A possible solution is override TargetLowering::LowerCallTo and do not > expand i64 arguments. I don't know if it's a good solution. None > backend overrides this function. Yes, you need to override both LowerArguments...