search for: expandlibcall

...it portions of 64-bit source operands. In customize for the operations, I am trying to do something like: case ISD::MUL: { EVT OpVT = Op.getValueType(); if (OpVT == MVT::i64) { RTLIB::Libcall LC = RTLIB::MUL_I64; SDValue Dummy; return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); } else if (OpVT == MVT::i32){ ??? What to do here to not have issues with type i32 } } I've gone a few directions on this. Defining the architecture type i32 leads to a lot of changes that I don't think...

...class The legalizer sees that 16-bit addition should expand. It sees that there is a 16-bit register class, and it sees that 16-bit values are legal. As 16-bit is legal, it does not try and expand into a smaller type (8-bit). This causes instruction selection to fail. I can see why you’d want ExpandLibCall to be a separate action. Our overhanging problem is that the legalizer only gives very coarse-grained control over the way it legalizes values. ​ On Thu, Aug 13, 2015 at 2:14 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > On Aug 12, 2015, at 10:25 AM, Dylan McKay via llvm-dev &l...

...directly to the target specific node. > When the LowerOperation method is called with a call node I create a new chain of operations and the return the a new operand. However, as you say, printing the DAG shows that not all the uses are replaced. I tracked this down to SelectionDAGLegalize::ExpandLibCall(). Here the TargetLowering's LowerCallTo is called to create the call node, which returns a pair of operands for the chain and the result. The chain is legalized but the result isn't. Modifying the code to call LegalizeOp on the result seems to fix the problem I was having: the code compile...

...In customize for the operations, I am trying to do something like: > > case ISD::MUL: > { > EVT OpVT = Op.getValueType(); > if (OpVT == MVT::i64) { > RTLIB::Libcall LC = RTLIB::MUL_I64; > SDValue Dummy; > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > } > else if (OpVT == MVT::i32){ > > ??? What to do here to not have issues with type i32 > } > } > > > I've gone a few directions on this. > > Defining the architecture ty...

On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: > Evan Cheng wrote: >> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >> >>> I'm trying to write a backend for a target with no hardware floating >>> point support. I've added a single i32 register class. I'm wanting >>> all >>> floating point operations to be lowered to

Hello all, I would like to propose a large change to LLVM that I would be happy to implement. The instruction selection legalizer knows of three different ways to legalize an action (ignoring an already legal action). - Expansion - Promotion - Custom Expanding a node will lead to one of two things - the operation will be split into several equivalent smaller operations (i.e. 64-bit

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...gLoc dl); void LegalizeSetCC(MVT VT, SDValue &LHS, SDValue &RHS, SDValue &CC, DebugLoc dl) { - LegalizeSetCCOperands(LHS, RHS, CC, dl); + LHS = LegalizeOp(LHS); + RHS = LegalizeOp(RHS); LegalizeSetCCCondCode(VT, LHS, RHS, CC, dl); } SDValue ExpandLibCall(RTLIB::Libcall LC, SDNode *Node, bool isSigned, SDValue &Hi); - SDValue ExpandIntToFP(bool isSigned, MVT DestTy, SDValue Source, DebugLoc dl); SDValue EmitStackConvert(SDValue SrcOp, MVT SlotVT, MVT DestVT, DebugLoc dl); SDValue ExpandBUILD_VECTOR(SDNode *Nod...

...arget could be extended to handle that and this would require only minor changes. c) LLVM libcalls currently pass their parameters on stack. But on some embedded systems FP support routines expect parameters on specific registers. At the moment, SelectionDAGLegalize::ExpandLibCall() explicitly uses CallingConv::C, but it could be made customizable by introducing a special libcall calling convention or even better by allowing the target specific lowering of libcalls. Actually it can be combined with the solution for (b). In this case target-specific lowering can take care abo...

Evan Cheng wrote: > On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: > >> I'm trying to write a backend for a target with no hardware floating >> point support. I've added a single i32 register class. I'm wanting all >> floating point operations to be lowered to library function calls. For >> the most part LLVM seems to get this right. For example

...target backend has to generate a libcall, shouldn't there be an exposed API to do this? Or should there be another bit added to the Legal/Custom/Expand/Promote enum to force generation of a libcall? I'm trying to avoid duplicating work already done in the SelectionDAGLegalize source (ExpandLibCall) and want to make sure that both the call and the callseq_end are properly legalzed. -scooter

...e I create a > new > chain of operations and the return the a new operand. However, as > you say, > printing the DAG shows that not all the uses are replaced. Are you examining the DAG before you lower the ISD::CALL node? > > > I tracked this down to SelectionDAGLegalize::ExpandLibCall(). > Here the TargetLowering's LowerCallTo is called to create the call > node, > which returns a pair of operands for the chain and the result. The > chain > is legalized but the result isn't. Modifying the code to call > LegalizeOp on > the result seems to fix t...

...r changes. Yes, TargetLowering would be a natural place to put this. Patches welcome :) > c) LLVM libcalls currently pass their parameters on stack. But on some > embedded systems FP support routines expect parameters on specific > registers. > At the moment, SelectionDAGLegalize::ExpandLibCall() explicitly uses > CallingConv::C, but it could be made customizable by introducing a > special libcall calling convention or even better by allowing the > target specific lowering of libcalls. Actually it can be combined with > the solution for (b). In this case target-specific loweri...

...rying to do something like: > > > > case ISD::MUL: > > { > > EVT OpVT = Op.getValueType(); > > if (OpVT == MVT::i64) { > > RTLIB::Libcall LC = RTLIB::MUL_I64; > > SDValue Dummy; > > return ExpandLibCall(LC, Op, DAG, false, Dummy, *this); > > } > > else if (OpVT == MVT::i32){ > > > > ??? What to do here to not have issues with type i32 > > } > > } > > > > > > I've gone a few directions on thi...

...<multiple use> 0x9c071a0: <multiple use> 0x9c08c98: <multiple use> 0x9c08d08: ch = RETSP 0x9c08c98, 0x9c071a0, 0x9c08c98:1 Where BL and RETSP are target specific nodes for a call and and return respectively. > >> I tracked this down to SelectionDAGLegalize::ExpandLibCall(). >> Here the TargetLowering's LowerCallTo is called to create the call >> node, >> which returns a pair of operands for the chain and the result. The >> chain >> is legalized but the result isn't. Modifying the code to call >> LegalizeOp on >&g...