[PATCH] D35901: [DAG] Improve candidate pruning in store merge failure case. NFC.

[Nirav Dave via Phabricator via llvm-commits]

niravd created this revision.

When we fail to find a mergeable sequence of candidates from the
sorted set of store merge candidates, we drop the initial store from
the candidate list and check again. However, the only property that
may change in our merge viability check by dropping some consecutive
candidates is the alignment of the first store, so we can safely drop
all candidates until a store with a better alignment is found.


https://reviews.llvm.org/D35901

Files:
  lib/CodeGen/SelectionDAG/DAGCombiner.cpp


Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp
===================================================================
--- lib/CodeGen/SelectionDAG/DAGCombiner.cpp
+++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp
@@ -12844,7 +12844,19 @@
 
       // Check if we found a legal integer type that creates a meaningful merge.
       if (LastLegalType < 2 && LastLegalVectorType < 2) {
-        StoreNodes.erase(StoreNodes.begin(), StoreNodes.begin() + 1);
+        // We have already checked that candidate stores are in order
+        // and of correct shape. While there is no mergable sequence
+        // from the beggining one may start later in the sequence. The
+        // only reason a merge of size N could have failed where
+        // another of the same size would not have does not is if the
+        // alignment has improved. Drop as many candidates as we can
+        // here.
+        unsigned NumSkip = 1;
+        while ((NumSkip < NumConsecutiveStores) &&
+               (StoreNodes[NumSkip].MemNode->getAlignment() <= FirstStoreAlign))
+          NumSkip++;
+
+        StoreNodes.erase(StoreNodes.begin(), StoreNodes.begin() + NumSkip);
         continue;
       }
 
@@ -12900,6 +12912,23 @@
           NumStoresToMerge = i + 1;
       }
 
+      // Check if we found a legal integer type that creates a meaningful merge.
+      if (NumStoresToMerge < 2) {
+        // We have already checked that candidate stores are in order
+        // and of correct shape. While there is no mergable sequence
+        // from the beggining one may start later in the sequence. The
+        // only reason a merge of size N could have failed where
+        // another of the same size would not have does not is if the
+        // alignment has improved. Drop as many candidates as we can here.
+        unsigned NumSkip = 1;
+        while ((NumSkip < NumConsecutiveStores) &&
+               (StoreNodes[NumSkip].MemNode->getAlignment() <= FirstStoreAlign))
+          NumSkip++;
+
+        StoreNodes.erase(StoreNodes.begin(), StoreNodes.begin() + NumSkip);
+        continue;
+      }
+
       bool Merged = MergeStoresOfConstantsOrVecElts(
           StoreNodes, MemVT, NumStoresToMerge, false, true, false);
       if (!Merged) {


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D35901.108310.patch
Type: text/x-patch
Size: 2236 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170726/221044f7/attachment.bin>