[llvm-commits] [llvm] r61946 - in /llvm/trunk: include/llvm/Transforms/Utils/InlineCost.h lib/Transforms/Utils/InlineCost.cpp test/Transforms/Inline/2009-01-08-NoInlineDynamicAlloca.ll test/Transforms/Inline/dynamic_alloca_test.ll test/Transforms/PruneEH/2008-09-05-CGUpdate.ll
Chris Lattner
clattner at apple.com
Thu Jan 8 14:48:17 PST 2009
On Jan 8, 2009, at 1:45 PM, Dale Johannesen wrote:
> Author: johannes
> Date: Thu Jan 8 15:45:23 2009
> New Revision: 61946
>
> URL: http://llvm.org/viewvc/llvm-project?rev=61946&view=rev
> Log:
> Do not inline functions with (dynamic) alloca into
> functions that don't already have a (dynamic) alloca.
> Dynamic allocas cause inefficient codegen and we shouldn't
> propagate this (behavior follows gcc). Two existing tests
> assumed such inlining would be done; they are hacked by
> adding an alloca in the caller, preserving the point of
> the tests.
Nice!
>
> + if (const AllocaInst *AI = dyn_cast<AllocaInst>(II)) {
> + if (!isa<ConstantInt>(AI->getArraySize()))
> + this->usesDynamicAlloca = true;
It's a very minor thing, but i'd prefer: if (!AI->isStaticAlloca()).
This will handle fixed-size allocas that are not in the entry block
also.
> + // Get infomation about the caller...
> + FunctionInfo &CallerFI = CachedFunctionInfo[Caller];
> +
> + // If we haven't calculated this information yet, do so now.
> + if (CallerFI.NumBlocks == 0)
> + CallerFI.analyzeFunction(Caller);
Please only analyze the caller here if CalleeFI.usesDynamicAlloca is
true.
Ok. One risk of this is that this could cause inaccurate inlining
costs to be computed (I think). Is this scenario possible?:
1. foo calls bar. Bar has a dynamic alloca, so we call
analyzeFunction on foo.
2. foo calls baz, we inline baz into foo.
3. gar calls foo, when analyzing the call to foo in gar, we look at
the inlining cost of foo.
Does the inlining cost of foo in #3 include the fact that baz got
inlined into foo?
If this is not already being handled, one good way to do this is to
have the "is analyzed" state for a function get cleared whenever
another function is inlined into it.
Thanks for working on this Dale, this is a great change,
-Chris
More information about the llvm-commits
mailing list