[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