[llvm] r259915 - CallAnalyzer::analyzeCall: change the condition back to "Cost < Threshold"
Easwaran Raman via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 24 16:19:50 PST 2016
I'm curious about the cause of the size regression. The effect of r252595
1. Inline zero-cost callees even if the threshold is negative or 0.
2. Inline positive-cost callees when they equal to the threshold (as
opposed to less than the threshold).
This change only reverts the effect 2 above. If that fixes the size
regression, is it the case that a lot of callees had cost equal to
threshold and the inlining decision got reversed? That could happen of
course, but I doubt that should cause a significant regression. I suspect
there are other subtle bugs in the code, so looking at specific instances
will be useful.
On Fri, Feb 5, 2016 at 12:32 PM, Hans Wennborg via llvm-commits <
llvm-commits at lists.llvm.org> wrote:
> Author: hans
> Date: Fri Feb 5 14:32:42 2016
> New Revision: 259915
> URL: http://llvm.org/viewvc/llvm-project?rev=259915&view=rev
> CallAnalyzer::analyzeCall: change the condition back to "Cost < Threshold"
> In r252595, I inadvertently changed the condition to "Cost <= Threshold",
> which caused a significant size regression in Chrome. This commit rectifies
> Modified: llvm/trunk/lib/Analysis/InlineCost.cpp
> --- llvm/trunk/lib/Analysis/InlineCost.cpp (original)
> +++ llvm/trunk/lib/Analysis/InlineCost.cpp Fri Feb 5 14:32:42 2016
> @@ -1392,7 +1392,7 @@ bool CallAnalyzer::analyzeCall(CallSite
> else if (NumVectorInstructions <= NumInstructions / 2)
> Threshold -= (FiftyPercentVectorBonus - TenPercentVectorBonus);
> - return Cost <= std::max(0, Threshold);
> + return Cost < std::max(1, Threshold);
> #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits