aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/InlineCost.cpp
diff options
context:
space:
mode:
authorAmara Emerson <aemerson@apple.com>2020-06-12 10:19:28 -0700
committerAmara Emerson <aemerson@apple.com>2020-06-24 17:39:03 -0700
commit090c108d04e2c557047f1d798dd56afcabe99373 (patch)
tree9115682c4359f832478707d491904a97f22bac86 /llvm/lib/Analysis/InlineCost.cpp
parent7d1452d8373e5aaaa94b5d0d6c9a1dc4be457311 (diff)
downloadllvm-090c108d04e2c557047f1d798dd56afcabe99373.zip
llvm-090c108d04e2c557047f1d798dd56afcabe99373.tar.gz
llvm-090c108d04e2c557047f1d798dd56afcabe99373.tar.bz2
Don't inline dynamic allocas that simplify to huge static allocas.
Some sequences of optimizations can generate call sites which may never be executed during runtime, and through constant propagation result in dynamic allocas being converted to static allocas with very large allocation amounts. The inliner tries to move these to the caller's entry block, resulting in the stack limits being reached/bypassed. Avoid inlining functions if this would result. The threshold of 64k currently doesn't get triggered on the test suite with an -Os LTO build on arm64, care should be taken in changing this in future to avoid needlessly pessimising inlining behaviour. Differential Revision: https://reviews.llvm.org/D81765
Diffstat (limited to 'llvm/lib/Analysis/InlineCost.cpp')
-rw-r--r--llvm/lib/Analysis/InlineCost.cpp12
1 files changed, 12 insertions, 0 deletions
diff --git a/llvm/lib/Analysis/InlineCost.cpp b/llvm/lib/Analysis/InlineCost.cpp
index f69c7f3..c05d1ee7 100644
--- a/llvm/lib/Analysis/InlineCost.cpp
+++ b/llvm/lib/Analysis/InlineCost.cpp
@@ -853,10 +853,22 @@ bool CallAnalyzer::visitAlloca(AllocaInst &I) {
if (I.isArrayAllocation()) {
Constant *Size = SimplifiedValues.lookup(I.getArraySize());
if (auto *AllocSize = dyn_cast_or_null<ConstantInt>(Size)) {
+ // Sometimes a dynamic alloca could be converted into a static alloca
+ // after this constant prop, and become a huge static alloca on an
+ // unconditional CFG path. Avoid inlining if this is going to happen above
+ // a threshold.
+ // FIXME: If the threshold is removed or lowered too much, we could end up
+ // being too pessimistic and prevent inlining non-problematic code. This
+ // could result in unintended perf regressions. A better overall strategy
+ // is needed to track stack usage during inlining.
Type *Ty = I.getAllocatedType();
AllocatedSize = SaturatingMultiplyAdd(
AllocSize->getLimitedValue(), DL.getTypeAllocSize(Ty).getFixedSize(),
AllocatedSize);
+ if (AllocatedSize > InlineConstants::MaxSimplifiedDynamicAllocaToInline) {
+ HasDynamicAlloca = true;
+ return false;
+ }
return Base::visitAlloca(I);
}
}