search for: build_pair

Displaying 20 results from an estimated 24 matches for "build_pair".

2008 Sep 01
2
[LLVMdev] BUILD_TRIPLET node.
Currently I can use a BUILD_PAIR to make a pair of two arbitrary values to a desired result value. For example, I can make i8,build_pair = (i8, i8) or i16,build_pair = (i1, i8). This is turning out to very handy when I replace nodes during the expansion/legalization of types for my target. I was just wondering if we could go...
2019 Jan 02
5
Potential bug in SelectionDAGLegalize::ConvertNodeToLibcall()?
Hi, I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64 BUILD_SPE64 i32, i32' node, which can be seen at https://reviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not legal on line 24. There should be no bitcast(buildpair) anywhere in t...
2019 Jan 03
3
Potential bug in SelectionDAGLegalize::ConvertNodeToLibcall()?
...pproach? Comments from anyone else? - Justin On Wed, 2 Jan 2019 11:39:59 -0500 Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > It sounds like the legalizer is lowering `fmaxnum` to a libcall > because it is not a legal node for `f64` and in doing so, it is > producing the `build_pair` to reassemble the results of the libcall. > And presumably, it is assuming that the new nodes do not need > legalization or something along those lines. > > Justin, it would probably be good if you could provide the DAG before > and after legalization both with and without your pat...
2019 Jan 04
2
Potential bug in SelectionDAGLegalize::ConvertNodeToLibcall()?
...ustin On Wed, 2 Jan 2019 11:39:59 -0500 Nemanja Ivanovic <nemanja.i.ibm at gmail.com<mailto:nemanja.i.ibm at gmail.com>> wrote: > It sounds like the legalizer is lowering `fmaxnum` to a libcall > because it is not a legal node for `f64` and in doing so, it is > producing the `build_pair` to reassemble the results of the libcall. > And presumably, it is assuming that the new nodes do not need > legalization or something along those lines. > > Justin, it would probably be good if you could provide the DAG before > and after legalization both with and without your patc...
2019 Jan 04
2
Potential bug in SelectionDAGLegalize::ConvertNodeToLibcall()?
...gt; On Wed, 2 Jan 2019 11:39:59 -0500 >> Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: >> >> > It sounds like the legalizer is lowering `fmaxnum` to a libcall >> > because it is not a legal node for `f64` and in doing so, it is >> > producing the `build_pair` to reassemble the results of the libcall. >> > And presumably, it is assuming that the new nodes do not need >> > legalization or something along those lines. >> > >> > Justin, it would probably be good if you could provide the DAG before >> > and after...
2019 Jul 11
6
Glue to connect two nodes in LLVM backend
Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on
2017 Oct 23
2
EnableFastISel
...ther FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example in SelectionDAGISel::LowerArguments SDB->setValue(&Arg, Res); if (!TM.Options.EnableFastISel && Res.getOpcode() == ISD::BUILD_PAIR) { if (LoadSDNode *LNode = dyn_cast<LoadSDNode>(Res.getOperand(0).getNode())) if (FrameIndexSDNode *FI = dyn_cast<FrameIndexSDNode>(LNode->getBasePtr().getNode())) FuncInfo->setArgumentFrameIndex(&Arg, FI->getIndex()); } Is...
2012 Aug 15
0
[LLVMdev] More Back-End Porting Troubles
..."easy" manner? > > My other problem is the zext instruction from i32 to i64. In > principle, this is very easy on the TriCore. Zext the argument in the > lower part of the 64bit register pair and write 0 to higher part. > Finally, these parts are glued together using ISD::BUILD_PAIR. > However, when I try to insert such nodes into the DAG within > TriCoreTargetLowering, I run into an assertion: > > llc: > /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: > void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, > llvm::Dens...
2008 Sep 08
0
[LLVMdev] adde/addc
...CC = (N->getOpcode() == ISD::ADD) ? ISD::SETULT : ISD::SETUGT; SDOperand Carry = DAG.getSetCC(MVT::i32, Lo, LHSL, CarryCC); SDOperand Hi = DAG.getNode(N->getOpcode(), MVT::i32, LHSH, Carry); Hi = DAG.getNode(N->getOpcode(), MVT::i32, Hi, RHSH); // Merge the pieces return DAG.getNode(ISD::BUILD_PAIR, MVT::i64, Lo, Hi).Val; } In LowerOperation I lower add and sub using: case ISD::ADD: case ISD::SUB: return SDOperand(ExpandADDSUB(Op.Val, DAG),0); This is for LLVM 2.3. I've haven't updated to the head recently so there might be additional changes needed for the new legalize types inf...
2012 Aug 15
5
[LLVMdev] More Back-End Porting Troubles
...hese error messages in an "easy" manner? My other problem is the zext instruction from i32 to i64. In principle, this is very easy on the TriCore. Zext the argument in the lower part of the 64bit register pair and write 0 to higher part. Finally, these parts are glued together using ISD::BUILD_PAIR. However, when I try to insert such nodes into the DAG within TriCoreTargetLowering, I run into an assertion: llc: /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, llvm::DenseMap<llvm::SDValue, unsigned int...
2012 Aug 16
2
[LLVMdev] More Back-End Porting Troubles
...anner? >> >> My other problem is the zext instruction from i32 to i64. In >> principle, this is very easy on the TriCore. Zext the argument in the >> lower part of the 64bit register pair and write 0 to higher part. >> Finally, these parts are glued together using ISD::BUILD_PAIR. >> However, when I try to insert such nodes into the DAG within >> TriCoreTargetLowering, I run into an assertion: >> >> llc: >> /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: >> void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool...
2009 Apr 08
2
[LLVMdev] LegalizeFloatType:ExpandFloatRes_FADD
...lue Call = LibCallify(GetFPLibCall(N->getValueType(0), RTLIB::ADD_F32, RTLIB::ADD_F64, RTLIB::ADD_F80, RTLIB::ADD_PPCF128), N, false); assert(Call.getNode()->getOpcode() == ISD::BUILD_PAIR && "Call lowered wrongly!"); Lo = Call.getOperand(0); Hi = Call.getOperand(1); } But in 2.4 the function was: void DAGTypeLegalizer::ExpandFloatRes_FADD(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Ops[2]...
2008 Sep 08
6
[LLVMdev] adde/addc
My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this
2008 Jul 03
2
[LLVMdev] Problems expanding fcmp to a libcall
...nt <0> 0x97a3c78: <multiple use> 0x97a42a8: i32 = Register #1024 0x97a42e0: i32,ch = CopyFromReg 0x97a3c78, 0x97a42a8 0x97a3c78: <multiple use> 0x97a4350: i32 = Register #1025 0x97a4388: i32,ch = CopyFromReg 0x97a3c78, 0x97a4350 0x97a4200: f64 = build_pair 0x97a42e0, 0x97a4388 0x97a4200: <multiple use> 0x97a43e0: i64 = bit_convert 0x97a4200 0x97a43e0: <multiple use> 0x97a3da8: i32 = Constant <1> 0x97a4428: i32 = extract_element 0x97a43e0, 0x97a3da8 0x97a4490: ch = setuo 0x97a4200: <multiple use> 0x97a...
2012 Aug 16
0
[LLVMdev] More Back-End Porting Troubles
...>> My other problem is the zext instruction from i32 to i64. In > >> principle, this is very easy on the TriCore. Zext the argument in the > >> lower part of the 64bit register pair and write 0 to higher part. > >> Finally, these parts are glued together using ISD::BUILD_PAIR. > >> However, when I try to insert such nodes into the DAG within > >> TriCoreTargetLowering, I run into an assertion: > >> > >> llc: > >> /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: > >> void llvm::InstrEmitter::EmitM...
2008 Jul 02
0
[LLVMdev] Problems expanding fcmp to a libcall
On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > Evan Cheng wrote: >> 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
2020 Jan 28
2
Handling node through TargetLowering::LowerOperation vs TargetLowering::ReplaceNodeResults
Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at
2008 Jul 01
2
[LLVMdev] Problems expanding fcmp to a libcall
Evan Cheng wrote: > 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
2009 Dec 16
1
[LLVMdev] Using branches in lowered operations
Hi Evan, Thanks for the useful pointer. When trying to implement the example to my situation I ran into a strange issue that I don't know how to resolve. My target doesn't support 64-bit operations and so far all operations have been expanded using LLVM except for division and remainder. For division, LLVM only gives you the option of either calling an external library or custom lowering
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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