search for: addtoworklist

Hello LLVM, A recent commit creates the isIntDivCheap() target query. http://reviews.llvm.org/D12082 The current approach has a couple shortcomings. First, when targets decide divide is cheap, the DAGCombiner ignores obvious power-of-2 optimizations. In the targets I know, shifts are cheaper than divides in both speed and size. The target cannot see the value in the isIntDivCheap() call, so

...n is this: > > // Splat the sign bit into the register > SDValue SGN = > DAG.getNode(ISD::SRA, DL, VT, N0, > DAG.getConstant(VT.getScalarSizeInBits() - 1, DL, > getShiftAmountTy(N0.getValueType()))); > AddToWorklist(SGN.getNode()); > > // Add (N0 < 0) ? abs2 - 1 : 0; > SDValue SRL = > DAG.getNode(ISD::SRL, DL, VT, SGN, > DAG.getConstant(VT.getScalarSizeInBits() - lg2, DL, > getShiftAmountTy(SGN.getValueType()))); >...

...once 00971 // N is deleted from the DAG, since they too may now be dead or may have a 00972 // reduced number of uses, allowing other xforms. 00973 if (N->use_empty() && N != &Dummy) { 00974 for (unsigned i = 0, e = N->getNumOperands(); i != e; ++i) 00975 AddToWorkList(N->getOperand(i).getNode()); 00976 00977 DAG.DeleteNode(N); 00978 continue; 00979 } Or is it one of the corner cases mentioned in SelectionDAGISel.cpp:644? 00644 // Skip dead nodes. DAGCombiner is expected to eliminate all dead nodes, 00645 // but there are currentl...

Explicitly re-adding a node to be processed doesn't work, because the processing order is canonical. 2017-05-22 11:39 GMT-07:00 Nirav Davé <niravd at google.com>: > You can always explicitly add D to the worklist when you make the > transformation with AddToWorklist. Presuambly this was the cause for your > infinite loop. > > -Nirav > > > On Mon, May 22, 2017 at 2:07 PM, Amaury SECHET <deadalnix at gmail.com> > wrote: > >> The root problem is that, when A gets modified, D doesn't get added back >> to the worklist....

...eleted from the DAG, since they too may now be dead > or may have a > 00972 // reduced number of uses, allowing other xforms. > 00973 if (N->use_empty()&& N !=&Dummy) { > 00974 for (unsigned i = 0, e = N->getNumOperands(); i != e; ++i) > 00975 AddToWorkList(N->getOperand(i).getNode()); > 00976 > 00977 DAG.DeleteNode(N); > 00978 continue; > 00979 } I suspect they could be removed. Probably a helper function should be added for this and used all over the place. Also, the RAUW earlier can cause nodes to be unified (due t...

The root problem is that, when A gets modified, D doesn't get added back to the worklist. I could match the pattern on A, but the problem remains: when D gets modified, A do not get added back tot he worklist. I also considered ding several round of DAGCombine, but it is very easy to run into infinite loops, even with a fair amount of sanity checks. 2017-05-22 7:30 GMT-07:00 Nirav Davé

...e dead > >> or may have a > >> 00972 ? ? // reduced number of uses, allowing other xforms. > >> 00973 ? ? if (N->use_empty()&& ?N !=&Dummy) { > >> 00974 ? ? ? for (unsigned i = 0, e = N->getNumOperands(); i != e; ++i) > >> 00975 ? ? ? ? AddToWorkList(N->getOperand(i).getNode()); > >> 00976 > >> 00977 ? ? ? DAG.DeleteNode(N); > >> 00978 ? ? ? continue; > >> 00979 ? ? } > > > > I suspect they could be removed. ?Probably a helper function should be added > > for this and used all over the pl...