search for: selectnodeto

...ssion. I've now looked at your latest patch. In summary, it does expose a subtle problem. I haven't seen anything that here would lead to observable misbehavior yet though. X86GenDAGISel.inc has code like this: SDValue N1 = N->getOperand(1); ... SDNode *ResNode = CurDAG->SelectNodeTo(N, ...); ... ReplaceUses(SDValue(N1.getNode(), 1), SDValue(ResNode, 2)); If N was the only user of N1, and N1 isn't in the new operand list, then the SelectNodeTo call will make N1 dead. SelectNodeTo will automatically delete nodes that are made dead by the transformation. This means tha...

On Friday 26 February 2010 10:34:41 David Greene wrote: > On Friday 26 February 2010 09:55:32 David Greene wrote: > > In the continuing quest to try to track down problems we're seeing in > > SelectionDAG, I added the following assert > > toSelectionDAG::ReplaceAllUsesOfValuesWith: > > Here's a patch to add more of these deleted node asserts. They fire > tons

...nced it to generate some somewhat-seemingly-reasonably-correct matching and generation code. What's happening is that that generation code constructs two MOVSD2PD instructions. These are all brand-new SDNodes. The very last step of the generation code calls SDNode *RetVal = CurDAG->SelectNodeTo(N.Val, Opc2, VT2, Tmp1, Tmp3, Tmp5); where N is the vector_shuffle node. and the Tmp variables are the two MOVSD2PD instructions and the shuffle mask. SelectNodeTo does an in-place replacement of the machine-independent SDNode (vector_shuffle)with a machine-dependent one (the SHUFPD). When w...

...hat-seemingly-reasonably-correct matching and generation code. > > What's happening is that that generation code constructs two MOVSD2PD > instructions. These are all brand-new SDNodes. The very last step > of the > generation code calls > > SDNode *RetVal = CurDAG->SelectNodeTo(N.Val, Opc2, VT2, Tmp1, Tmp3, > Tmp5); > > where N is the vector_shuffle node. and the Tmp variables are the two > MOVSD2PD instructions and the shuffle mask. SelectNodeTo does an in- > place > replacement of the machine-independent SDNode (vector_shuffle)with a > machine-...

...ng the AVR backend. It is still in the early stage. I got the following error:[ 86%] Building CXX object lib/Target/AVR/CMakeFiles/LLVMAVRCodeGen.dir/AVRISelDAGToDAG.cpp.obj AVRISelDAGToDAG.cpp C:\llvm-build\lib\Target\AVR\AVRGenDAGISel.inc(596) : error C2664: 'llvm::SDNode *llvm::SelectionDAG::SelectNodeTo(llvm::SDNode *,unsigned int,llvm::MVT,llvm::MVT,llvm::MVT,const llvm::SDValue *,unsigned int)' : cannot convert parameter 6 from 'llvm::SDValue' to 'const llvm::SDValue *' No user-defined-conversion operator available that can perform this conv ersion, or the operator ca...

...behavior yet though. Well, I'm definitely observing misbehavior. I know it has something to do with local changes here but I haven't isolated it yet. > X86GenDAGISel.inc has code like this: > > SDValue N1 = N->getOperand(1); > ... > SDNode *ResNode = CurDAG->SelectNodeTo(N, ...); > ... > ReplaceUses(SDValue(N1.getNode(), 1), SDValue(ResNode, 2)); > > If N was the only user of N1, and N1 isn't in the new operand list, then > the SelectNodeTo call will make N1 dead. SelectNodeTo will automatically > delete nodes that are made dead by the t...

On Fri, October 3, 2008 9:10 am, David Greene wrote: > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection >> loads have multiple uses, so even though you've managed to match a >> larger pattern that incorporates them, they still need to exist to >> satisfy some other users. > > Yes,

On Tuesday 07 October 2008 15:24, Dan Gohman wrote: > It should. SelectNodeTo is a wrapper around MorphNodeTo, and MorphNodeTo > has code to check for and remove nodes that become dead, specifically to > address this case. If that's not working, it's a bug. > > What version of LLVM are you using here? This is code that has changed > substantially over...

On Thursday 02 October 2008 19:32, Dan Gohman wrote: > Looking at your dump() output above, it looks like the pre-selection > loads have multiple uses, so even though you've managed to match a > larger pattern that incorporates them, they still need to exist to > satisfy some other users. Yes, I looked at that too. It looks like these other uses end up being chains to

...tions. As far as I can understand things, the problem is that the two MOVSD instructions are generated by a recursive call to EmitResultCode. Thus isRoot is false and the result of the call to getTargetNode is not passed to ReplaceUses. Then when we pop back up and generate the SHUFPD we call SelectNodeTo which only transforms the immediate node (the vector_shuffle). It doesn't recurse to replace child nodes. I tried hacking tblgen to call getTargetNode / ReplaceUses if any node in the pattern has a chain by changing this line in tblgen: bool InputHasChain = isRoot &&...

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

...de). All of the "Implement Select instead of SelectImpl" commits do some of this. 4. Where a utility function can return null when Select should fall back to another selector, rename that to try*, have it call ReplaceNode, and return a bool for success. 5. Where something calls SelectNodeTo, just return afterwards (SelectNodeTo does the appropriate replacement). Hope that helps! > I will examine the X86 implementation as you recommend and hope to > glean some knowledge from that. > > All the best, > > MartinO > > -----Original Message----- > From: Ahme...

...t; what's wrong here? SDValue Chain = N->getOperand(0); SDValue Target = N->getOperand(1); unsigned Opc = PPC::MTCTR8; unsigned Reg = PPC::BCTR8; Chain = SDValue(CurDAG->getMachineNode(Opc, dl, MVT::Other, Target, Chain), 0); return CurDAG->SelectNodeTo(N, Reg, MVT::Other, Chain); Thanks again, Hal > > /jakob > -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

Thanks Ahmed and also Alex for your replies. This is more or less what I was realising, but it is a great confidence booster to know that it is the correct way also. I can replace all of my various 'Select*' specialisations with version that use 'ReplaceNode/SelectCode' and return 'void', but what about the places where I currently call 'Select(N)' directly?

...eems to be correct. It seems that the problem is with function: SDNode *PPCDAGToDAGISel::Select(SDOperand Op) in PPCISelDAGtoDAG.cpp file with case ISD::ADD when it checks whenever and'ed constant is rotated first. In such case he puts PPC::RLWINM instruction into DAG (return CurDAG- >SelectNodeTo(N, PPC::RLWINM, MVT::i32, Ops, 4);) My question is: can I use patterns to fetch that - if yes, then how (there is no RLWINM SDNode). When that function is used, after or before legalization? I don't see anything on my printouts and that's a little confusing. Best greetings, Mariusz. --...

...Opc = Target.getValueType() == MVT::i32 ? PPC::MTCTR : PPC::MTCTR8; unsigned Reg = Target.getValueType() == MVT::i32 ? PPC::BCTR : PPC::BCTR8; Chain = SDValue(CurDAG->getMachineNode(Opc, dl, MVT::Other, Target, Chain), 0); return CurDAG->SelectNodeTo(N, Reg, MVT::Other, Chain); } Thanks in advance, Hal On Mon, 2011-12-05 at 13:14 -0600, Hal Finkel wrote: > On Mon, 2011-12-05 at 10:12 -0800, Jakob Stoklund Olesen wrote: > > On Dec 5, 2011, at 9:55 AM, Hal Finkel wrote: > > > > > Author: hfinkel > > > Date: M...

...he > pattern has a chain by changing this line in tblgen: > > bool InputHasChain = isRoot && > NodeHasProperty(Pattern, SDNPHasChain, CGP); > > to call PatternHasProperty instead. This does cause tblgen to emit > getTargetNode / ReplaceUses instead of SelectNodeTo but ReplaceUses doesn't > know how to handle a complex pattern like this. It complains about having > two many operands: > > assert(From->getNumValues() == 1 && FromN.ResNo == 0 && > "Cannot replace with this method!"); I don't im...

...be handled by the PPCDAGToDAGISel::Select function. This function always transforms SELECT_CC nodes into PPC-specific nodes that can be instruction selected; in doing so the ISD::SETLT (and all similar comparison operator nodes) should be dropped (they are not used in the node passed to CurDAG->SelectNodeTo). During instruction selected, PPCDAGToDAGISel::Select is called once on one of the SELECT_CC nodes, and then sometime later, CodeGen attempts to instruction-select the SETLT node (which fails, thus the bug). I don't understand why PPCDAGToDAGISel::Select would be called only on one of the SEL...

On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > RegScavenger is complaining about use of an undefined register, CTR8, in > the BCTR8 instruction, in the following instance (this is from the PPC > backend): > > BB#38: derived from LLVM BB %for.end50 > Predecessors according to CFG: BB#36 > %X3<def> = LD 0, <fi#27>; mem:LD8[FixedStack27] >

...gister #1024 [0] 0x213b610: i64 = undef I added the brackets on output to show which result is being linked to, so the prefetch takes the chain output from its controlling load. When llvm.x86.sse2.min.sd gets selected, the TableGen-generated code does this: SDNode *ResNode = CurDAG->SelectNodeTo(N.getNode(), Opc0, VT0, MVT::Other, Ops0, 6); 0x215f140: v2f64,ch = <<Unknown Machine Node>> 0x21606d0, 0x213ac00, 0x215ffa0, 0x215ea10, 0x215ee60, 0x213a720 [0] 0x21606d0: v2f64 = scalar_to_vector 0x213b8f0 [0] 0x213b8f0: f64,ch = load 0x213b780, 0x213aa90, 0x213b610 <0x2113690...