[PATCH] D84204: DADCombiner: Don't simplify the token factor if the node's number of operands already exceeds TokenFactorInlineLimit

Changpeng Fang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 20 21:16:34 PDT 2020


cfang created this revision.
cfang added reviewers: spatel, arsenm.
Herald added subscribers: steven.zhang, hiraditya, wdng.
Herald added a project: LLVM.

In parallelizeChainedStores, a TokenFactor was created with the size greater than 3000.
We found that DAGCombiner::visitTokenFactor will consume a huge amount of time on 
such nodes. Since the number of operands already exceeds TokenFactorInlineLimit, we propose
to give up simplification with the consideration of compile time.


https://reviews.llvm.org/D84204

Files:
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp


Index: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
===================================================================
--- llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
+++ llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
@@ -1805,6 +1805,10 @@
   if (OptLevel == CodeGenOpt::None)
     return SDValue();
 
+  // Don't simplify the token factor if the node itself has too many operands.
+  if (N->getNumOperands() > TokenFactorInlineLimit)
+    return SDValue();
+
   // If the sole user is a token factor, we should make sure we have a
   // chance to merge them together. This prevents TF chains from inhibiting
   // optimizations.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D84204.279353.patch
Type: text/x-patch
Size: 634 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200721/7e2752ff/attachment-0001.bin>


More information about the llvm-commits mailing list