[PATCH] Fix for inlining decision affected by debug intrinsics

Chandler Carruth chandlerc at google.com
Fri Jan 31 12:08:51 PST 2014


On Fri, Jan 31, 2014 at 12:06 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Fri, Jan 31, 2014 at 10:55 AM, Dario Domizioli <
> dario.domizioli at gmail.com> wrote:
>
>> I have come across a subtle and rare interaction between debug
>> information, vector instructions, and the cost heuristic used by the
>> SimpleInliner (i.e. the InlineCost analysis).
>>
>> It appears that debug intrinsics are counted in the number of
>> instructions taken into consideration by the heuristic. They are also later
>> discounted as being "simplified", so they do not directly affect the inline
>> Cost, but they are taken into account when evaluating the fraction of
>> instructions that are vector instructions. This fraction is used to
>> determine whether to apply a hidden "VectorBonus" to the inlining
>> Threshold, and therefore there is a subtle interaction which means that
>> debug intrinsics can affect the inlining decision.
>>
>> The attached patch fixes the problem by making the inline cost heuristic
>> skip debug intrinsics altogether when examining instructions.
>> I have also added a couple of debug prints to the already existing ones,
>> which I think are generally useful to debug the inline cost heuristic.
>>
>
> I don't think this bug has anything to do with debug info intrinsics, and
> so I don't think this is the correct patch.
>
> I think the bug is that instructions which we simplify away are counted
> toward the vector bonus. There should be no difference between debug info
> intrinsics and lifetime intrinsics. So the fix should be general and apply
> to the the basic cost.
>
>
> However, as a meta point, the "vector bonus" is the single worst aspect of
> our inline heuristics. To an extent, I would rather *remove* the vector
> bonus than make it more correct... but perhaps that battle is best fought
> another day.
>

Actually, the more I think about it, the more I think that this is a sign
the vector bonus *really* needs to go away. Fixing this (very serious)
problem with how we compute the vector bonus will have the effect of
significantly increasing our willingness to inline functions which contain
any vector code. Combined with the SLP vectorizer, this will cause the
inline threshold to change for a completely inscrutable X% of functions
where X is likely between 20 and 50. That was never the intent of the
heuristic (identified as trying to make loop kernels inline better) and so
I'm now somewhat worried about regressions if we fix this. Ugh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140131/7598a42a/attachment.html>


More information about the llvm-commits mailing list