search for: updatenodeoperand

Displaying 20 results from an estimated 20 matches for "updatenodeoperand".

Did you mean: updatenodeoperands
2013 Nov 26
2
[LLVMdev] R600/SI build failure on Leopard (Use of C++11)
...this to SIISelLowering.cpp: // Adjust the writemask in the node std::vector<SDValue> Ops; Ops.push_back(DAG.getTargetConstant(NewDmask, MVT::i32)); for (unsigned i = 1, e = Node->getNumOperands(); i != e; ++i) Ops.push_back(Node->getOperand(i)); Node = (MachineSDNode*)DAG.UpdateNodeOperands(Node, Ops.data(), Ops.size()); That fails with Leopard's libstdc++ STL which does not a data method for std::vector. This method was added in C++11: http://www.cplusplus.com/reference/vector/vector/ Is llvm-3.4 now requiring a C++11 runtime? If not, can we solve this a different way? Than...
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
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...back(Node->getOperand(1)); // line # must be legal. + Ops.push_back(Node->getOperand(2)); // col # must be legal. Ops.push_back(Node->getOperand(3)); // filename must be legal. Ops.push_back(Node->getOperand(4)); // working dir # must be legal. Result = DAG.UpdateNodeOperands(Result, &Ops[0], Ops.size()); @@ -1341,19 +1064,12 @@ switch (TLI.getOperationAction(ISD::DEBUG_LOC, MVT::Other)) { default: assert(0 && "This action is not supported yet!"); case TargetLowering::Legal: { - LegalizeAction Action = getTypeAction(Node->ge...
2013 Nov 26
0
[LLVMdev] R600/SI build failure on Leopard (Use of C++11)
...gt; // Adjust the writemask in the node > std::vector<SDValue> Ops; > Ops.push_back(DAG.getTargetConstant(NewDmask, MVT::i32)); > for (unsigned i = 1, e = Node->getNumOperands(); i != e; ++i) > Ops.push_back(Node->getOperand(i)); > Node = (MachineSDNode*)DAG.UpdateNodeOperands(Node, Ops.data(), Ops.size()); > > That fails with Leopard's libstdc++ STL which does not a data method for std::vector. This method was added in C++11: > http://www.cplusplus.com/reference/vector/vector/ > > Is llvm-3.4 now requiring a C++11 runtime? If not, can we solve this...
2012 Nov 24
2
[LLVMdev] Fwd: Prevention register promotion at the isel codegen phase
...gt; > SmallVector<SDValue, 4> Ops; > unsigned NumOps = Node->getNumOperands(); > > for (unsigned i = 0; i < NumOps; ++i) { > if (i == OpNo) > Ops.push_back(Chain); > else > Ops.push_back(Node->getOperand(i)); > } > > CurDAG->UpdateNodeOperands(Node, &Ops[0], NumOps); > > Note: you can't do this during ISelLowering because the combiner will just remove the store and load again unless you mark one or the other as volatile and that doesn't seem like the right thing to do. > > Hope that helps. > > On 23 Nov...
2012 Nov 24
0
[LLVMdev] Fwd: Prevention register promotion at the isel codegen phase
...; > > SmallVector<SDValue, 4> Ops; > unsigned NumOps = Node->getNumOperands(); > > for (unsigned i = 0; i < NumOps; ++i) { > if (i == OpNo) > Ops.push_back(Chain); > else > Ops.push_back(Node->getOperand(i)); > } > > CurDAG->UpdateNodeOperands(Node, &Ops[0], NumOps); > > Note: you can't do this during ISelLowering because the combiner will just > remove the store and load again unless you mark one or the other as > volatile and that doesn't seem like the right thing to do. > > Hope that helps. > > On...
2008 Oct 26
6
[LLVMdev] Turning on LegalizeTypes by default
...I plan to progressively delete type legalization functionality from LegalizeDAG, checking that LegalizeTypes has the same functionality as I go, and adding it if not. Testsuite results are as follows: (a) "make check" has two failures: ARM/cse-libcalls.ll - this is because of a bug in UpdateNodeOperands which does not do CSE on calls correctly. The question here is how best to fix this while minimizing code duplication. This will doubtless be fixed soon. PowerPC/vec_spat.ll (@splat_h) - here code got slightly worse. The problem here is that LegalizeDAG "cheats": it constructs a BUI...
2013 Feb 07
1
[LLVMdev] Legalizing FrameIndex
Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where
2009 Feb 23
2
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...when it's called repeatedly. However, (b) is something that is handled elsewhere. BuildVectorSDNode is merely a container class -- the constructor isn't doing anything funky other than calling the base constructor with the appropriate SDOperand list and size. I seem to recall that calling UpdateNodeOperands is generally frowned upon, but I'm happy to look into that particular issue. But at this point, I didn't see any place where a BUILD_VECTOR has its operands updated. Removing the result caching would avoid bugs, with which I agree. In my opinion, the proper direction for shuffles is: >...
2013 Nov 26
2
[LLVMdev] R600/SI build failure on Leopard (Use of C++11)
...the writemask in the node >> std::vector<SDValue> Ops; >> Ops.push_back(DAG.getTargetConstant(NewDmask, MVT::i32)); >> for (unsigned i = 1, e = Node->getNumOperands(); i != e; ++i) >> Ops.push_back(Node->getOperand(i)); >> Node = (MachineSDNode*)DAG.UpdateNodeOperands(Node, Ops.data(), Ops.size()); >> >> That fails with Leopard's libstdc++ STL which does not a data method for std::vector. This method was added in C++11: >> http://www.cplusplus.com/reference/vector/vector/ >> >> Is llvm-3.4 now requiring a C++11 runtime? If...
2009 Jun 25
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
On Jun 25, 2009, at 2:05 PM, Artjom K. wrote: > > Greetings, > > I am rather new to LLVM, so please excuse my limited knowledge about > it. > > Currently I am trying to modify the X86TargetLowering::LowerCALL > method by > inserting additional instructions before the call. > As far as I understand, nodes are created by calling the getNode > method on >
2009 Jun 26
2
[LLVMdev] Inserting nodes into SelectionDAG (X86)
...s.push_back(DAG.getConstant(1, MVT::i32)); Ops.push_back(InFlag); Chain = DAG.getNode(ISD::ADDC, DAG.getVTList(MVT::Other, MVT::Flag), &Ops[0], Ops.size()); InFlag = Chain.getValue(1); Usually, llc quits with the error message llc: SelectionDAG.cpp:4417: llvm::SDValue llvm::SelectionDAG::UpdateNodeOperands(llvm::SDValue, llvm::SDValue, llvm::SDValue): Assertion `N->getNumOperands() == 2 && "Update with wrong number of operands"' failed. Omiting the target register or switching operand order seems not to change anything. I'd really appreciate your help on this. Artjom --...
2007 Mar 30
1
[LLVMdev] Cleanups in ROTL/ROTR DAG combiner code
...case ISD::ROTR: Tmp1 = LegalizeOp(Node->getOperand(0)); // LHS Tmp2 = LegalizeOp(Node->getOperand(1)); // RHS - - assert(TLI.isOperationLegal(Node->getOpcode(), Node->getValueType(0)) && - "Cannot handle this yet!"); Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2); + switch (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0))) { + default: + assert(0 && "ROTL/ROTR legalize operation not supported"); + break; + case TargetLowering::Legal: + break; + case TargetLowering::Custo...
2009 Jun 25
2
[LLVMdev] Inserting nodes into SelectionDAG (X86)
Greetings, I am rather new to LLVM, so please excuse my limited knowledge about it. Currently I am trying to modify the X86TargetLowering::LowerCALL method by inserting additional instructions before the call. As far as I understand, nodes are created by calling the getNode method on the DAG. If, for example, I insert the following code Ops.push_back(Chain); Chain = DAG.getNode(ISD::TRAP,
2009 Feb 23
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...; > However, (b) is something that is handled elsewhere. > BuildVectorSDNode is merely a container class -- the constructor > isn't doing anything funky other than calling the base constructor > with the appropriate SDOperand list and size. I seem to recall that > calling UpdateNodeOperands is generally frowned upon, but I'm happy > to look into that particular issue. But at this point, I didn't see > any place where a BUILD_VECTOR has its operands updated. Removing > the result caching would avoid bugs, with which I agree. Once you remove the caching, there...
2008 Oct 26
0
[LLVMdev] Turning on LegalizeTypes by default
...galizing a uitofp from 32-bit to double turns into a 64-bit sitofp on x87. Just expect a bit of fallout when removing chunks from legalizedag. > Testsuite results are as follows: > > (a) "make check" has two failures: > ARM/cse-libcalls.ll - this is because of a bug in UpdateNodeOperands > which does not do CSE on calls correctly. The question here is how > best > to fix this while minimizing code duplication. This will doubtless be > fixed soon. Ok. > PowerPC/vec_spat.ll (@splat_h) - here code got slightly worse. The > problem here is that LegalizeDAG &q...
2006 Aug 25
4
[LLVMdev] Built LLVM 1.8 on VC8, invalid iterator issue/fix, some questions
...> Ops; for (unsigned i = 0, e = Use->getNumOperands(); i != e; ++i){ SDOperand O = Use->getOperand(i); if (O.Val == From.Val) Ops.push_back(To); else Ops.push_back(O); } SDOperand U = SDOperand(Use, 0); CurDAG->UpdateNodeOperands(U, Ops); // *** This invalidates the UI iterator *** } } } This causes lli to crash on the ++UI in the for loop (assert failure in debug mode, hard crash nearby in release mode) if I try to run bytecode generated from this LLVM code: %blah = global int 5 implementation int %main()...
2009 Feb 23
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
On Feb 23, 2009, at 1:20 PM, Scott Michel wrote: > Chris: > > I did float this by the dev list first a couple of weeks ago, didn't > receive any comments. Ok, I didn't see it, sorry about that. > It's not entirely gratuitous; the rationale for adding a new node > class is threefold: > > a) Convenience for the backends. Since it benefits multiple backends
2009 Feb 23
4
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
Chris: I did float this by the dev list first a couple of weeks ago, didn't receive any comments. It's not entirely gratuitous; the rationale for adding a new node class is threefold: a) Convenience for the backends. Since it benefits multiple backends (PPC and CellSPU), it's a logical addition. I reckon the GPU efforts would also benefit. b) Where else would one encapsulate a