search for: updatenodeoperands

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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,

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

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

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

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

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