<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 31, 2014 at 12:06 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Fri, Jan 31, 2014 at 10:55 AM, Dario Domizioli <span dir="ltr"><<a href="mailto:dario.domizioli@gmail.com" target="_blank">dario.domizioli@gmail.com</a>></span> wrote:<br>

</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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).</div>


<div><br></div><div>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.</div>


<div><br></div><div>The attached patch fixes the problem by making the inline cost heuristic skip debug intrinsics altogether when examining instructions.</div><div>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.</div>

</blockquote></div></div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

</div>
</blockquote></div><br></div><div class="gmail_extra">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.</div>
</div>