This is an archive of the discontinued LLVM Phabricator instance.

Use updated threshold for indirect call bonus
ClosedPublic

Authored by eraman on Nov 3 2015, 3:51 PM.

Details

Summary

When considering foo->bar inlining, if there is an indirect call in foo which gets resolved to a direct call (say baz), then we try to inline baz into bar with a threshold T and subtract max(T - Cost(bar->baz), 0) from Cost(foo->bar). This patch uses max(Threshold(bar->baz) - Cost(bar->baz)) instead, where Threshold(bar->baz) could be different from T due to bonuses or subtractions. This seems more logical to me since Threshold(bar->baz) - Cost(bar->baz) represents the desirability of inlining baz into bar than T - Cost(bar->baz), 0.

Diff Detail

Repository
rL LLVM

Event Timeline

eraman updated this revision to Diff 39127.Nov 3 2015, 3:51 PM
eraman retitled this revision from to Use updated threshold for indirect call bonus.
eraman updated this object.
eraman added a reviewer: chandlerc.
eraman set the repository for this revision to rL LLVM.
eraman added subscribers: llvm-commits, davidxl.

yes, this makes more sense to me.

Conceptually, CA.getThreshold() represents the cost if the call site remains *uninlined*, so that Threshold - Cost really means the benefit/gain of doing the inlining.

However since the cost of keeping and indirect call site 'uninlined' can be slightly higher than the regular direct callsite (due to indirect branch), it might be better to introduce a small booster InlineConstants::IndirectCallCost:

Cost -= std::max(0, CA.getThreshold() + InlineConstants::IndirectCallCost - CA.getCost());

Also if InlineConstants::IndirectCallThreshold is not used anywhere, get rid of it.

I had a comment there -- remove the IndirectCallThreshold if not needed. The boost parameter suggestion can be done as a followup.

eraman added a comment.Dec 2 2015, 1:12 PM

Also if InlineConstants::IndirectCallThreshold is not used anywhere, get rid of it.

It is being used in creating the CallAnalyzer object - this is the threshold we want to begin with.

davidxl accepted this revision.Dec 3 2015, 1:02 PM
davidxl added a reviewer: davidxl.
This revision is now accepted and ready to land.Dec 3 2015, 1:02 PM
This revision was automatically updated to reflect the committed changes.
chandlerc edited edge metadata.Dec 8 2015, 1:54 AM

While the source code change here makes sense, there is no test added which is not acceptable, and there was no explicit LGTM.

David, just marking a patch as accepted in Phabricator doesn't send an email. Please actually write an LGTM in the comment box and send that so others are aware.

Also, David, I would suggest waiting for others to give a final approval for changes to the inline cost mechanisms, as this isn't really an area of LLVM that you've done extensive work on (yet). Also, it isn't appropriate to LGTM this without a test that ensures we don't regress.

Easwaran, please add a test.

David, just marking a patch as accepted in Phabricator doesn't send an email. Please actually write an LGTM in the comment box and send that so others are aware.

I've also filed a bug to track the fact that realistically we shouldn't need to remember this kind of stuff. The tools should just DTRT. http://llvm.org/PR25771

davidxl added inline comments.Dec 8 2015, 4:07 PM
llvm/trunk/lib/Analysis/InlineCost.cpp
834

I missed this unchanged line.

On second look at the patch, I think the patch is still not complete. We should not pass a fixed Threshold for indirect callsite here -- there are other factors that can boost the inlining for the callsite once it becomes direct -- think about PGO case where the indirect callsite is super hot.

Instead, as I said in previous comments, we should make IndirectCallThreshold as an additional booster (delta) on top of regular threshold computed.

The refactoring should be straight forward -- introduce a new function Inliner::getInlineThreshold that takes two arguments: 1) callsite; and 2) callee function decl.

Can you please help with this?

FWIW, this should really be in a separate patch rather than being combined
IMO.