[PATCH] D81765: Don't inline dynamic allocas that simplify to huge static allocas.

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 23 13:26:48 PDT 2020


efriedma added inline comments.


================
Comment at: llvm/include/llvm/Analysis/InlineCost.h:54
+/// static allocas above this amount in bytes.
+const uint64_t MaxSimplifiedDynamicAllocaToMove = 65536;
 } // namespace InlineConstants
----------------
jfb wrote:
> mtrofin wrote:
> > I think MaxSimplifiedDynamicAllocaToMove should be part of InlineParams, since it's a threshold. 
> It probably needs to be a per-target thing, since we want different values for userspace and kernel.
Rather than add a threshold for a single dynamic alloca, it might make sense to just pay attention to the overall size of the stack of the inlined function.  We currently have a threshold TotalAllocaSizeRecursiveCaller which applies to recursive inlining; we could apply a similar threshold to inlining in general.  That would avoid potential weird interactions with other passes about whether the alloca is actually dynamic.

It might make sense to let the user control that threshold; users running code on small stacks might care more about the stack size.  But really, I'm not sure there's a great way to solve "how much stack memory should we speculatively allocate" if we can't see the whole callstack.

But really, I'm fine with this patch as-is as a spot fix for "I accidentally allocated 2^34 bytes in dead code". We probably want to consider the general issue of stack usage more carefully.


================
Comment at: llvm/lib/Analysis/InlineCost.cpp:838
   if (I.isArrayAllocation()) {
     Constant *Size = SimplifiedValues.lookup(I.getArraySize());
----------------
aemerson wrote:
> efriedma wrote:
> > Hhow is the handling for array allocation supposed to work if the alloca isn't in the entry block of the function?  It looks like this code assumes that constant-propagation is enough to turn any dynamic alloca into a static alloca?
> > 
> > Not really a problem with this change, exactly, but I want to make sure I'm understanding the surrounding code correctly.
> I'm not entirely sure what you mean, but if an array allocation isn't in the entry block, and if constant prop can't simplify it to a static alloca, then it remains a dynamic alloca and the inliner gives up (see the end of this function).
My question is what happens if an array allocation isn't in the entry block, but we can simplify the size to a constant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81765/new/

https://reviews.llvm.org/D81765





More information about the llvm-commits mailing list