[DAG] Aggressively cleanup dangling node in CombineZExtLogicopShiftLoad.

[niravd]

Summary

While dangling nodes will eventually be pruned when they are
considered, leaving them disables combines requiring single-use.

[spatel]

Can you describe what's happening in these tests? Should we consider the x86 diffs (inc -> add) regressions?
I'm trying to figure out how I managed to get the same set of diffs in D57516. :)

[niravd]

Hmm , weird. I've been looking at reasons why D57367 is doing so much when I found the case generating dangling node. I _was_ a bit surprised that this causes that regression, but it must be the case that dangling nodes persist to ISel and prevent folding. Presumably your change allowed CombineZExtLogicOpShiftLoad to trigger.

In any case, this is obvious cleanup and rebasing past your revert this is NFCish as expected again. I'll land this presently.

[RKSimon]

@niravd was committing this intentional?

[spatel]

I see what happened here.
This patch was based on something after rL352766, so it picked up the test diffs that were mistakenly omitted by the first rev of D57516.
On its own, this patch shows no test diffs, so Nirav proceeded with committing this after rL352769.

D57516 has *no* interaction with this patch AFAICT. That makes a lot more sense than both patches tickling exactly the same set of regression tests.

I have a separate x86 patch in progress to avoid the add->inc seen in the other patch.

llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

SDValue DAGCombiner::CombineZExtLogicopShiftLoad(SDNode *N) {
   CombineTo(N, And);
   if (SDValue(Load, 0).hasOneUse()) {
     DAG.ReplaceAllUsesOfValueWith(SDValue(Load, 1), ExtLoad.getValue(1));
   } else {
     SDValue Trunc = DAG.getNode(ISD::TRUNCATE, SDLoc(Load),
                                 Load->getValueType(0), ExtLoad);
     CombineTo(Load, Trunc, ExtLoad.getValue(1));
   }
+
+  // N0 is dead at this point.
+  recursivelyDeleteUnusedNodes(N0.getNode());
+
   return SDValue(N,0); // Return N so it doesn't get rechecked!
 }
 
 /// If we're narrowing or widening the result of a vector select and the final
 /// size is the same size as a setcc (compare) feeding the select, then try to
 /// apply the cast operation to the select's operands because matching vector
 /// sizes for a select condition and other operands should be more efficient.
 SDValue DAGCombiner::matchVSelectOpSizesWithSetCC(SDNode *Cast) {