search for: build_pair

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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