This is an archive of the discontinued LLVM Phabricator instance.

Fix getInlineCost with ComputeFullInlineCost enabled
ClosedPublic

Authored by apilipenko on Oct 12 2021, 6:15 PM.

Details

Summary

getInlineCost delegates to InlineCostCallAnalyzer::analyze to do the actual analysis. Once the analysis is done getInlineCost tries to reverse engineer the result of the analysis in order to determine whether a detailed cost/threshold or a simple always/never should be returned.

// Check if there was a reason to force inlining or no inlining.
if (!ShouldInline.isSuccess() && CA.getCost() < CA.getThreshold())
  return InlineCost::getNever(ShouldInline.getFailureReason());
if (ShouldInline.isSuccess() && CA.getCost() >= CA.getThreshold())
  return InlineCost::getAlways("empty function");

return llvm::InlineCost::get(CA.getCost(), CA.getThreshold());

This reverse engineering fails when ComputeFullInlineCost is enabled. Specifically, InlineCostCallAnalyzer::analyze can fail due to non-inlinable instruction (e.g. noduplicate call). With ComputeFullInlineCost enabled the cost can be above the threshold. In this case, the old code incorrectly returns a cost/threshold pair instead of never.

We ran across this issue with a downstream user of InlineCost. I found that upstream SampleProfile uses getInlineCost with ComputeFullInlineCost, so I added a test case demonstrating the issue via SampleProfile.

To fix this issue I mimic the approach used by cost-benefit analysis and add an explicit flag to InlineCostCallAnalyzer indicating that the result was decided by cost-threshold analysis.

Diff Detail

Event Timeline

apilipenko created this revision.Oct 12 2021, 6:15 PM
apilipenko requested review of this revision.Oct 12 2021, 6:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 12 2021, 6:15 PM

Add a simple test case using -inline-cost-full cl::opt.

mtrofin accepted this revision.Oct 14 2021, 2:48 PM
mtrofin added a reviewer: kazu.
This revision is now accepted and ready to land.Oct 14 2021, 2:48 PM

Thanks for the fix!

We ran across this issue with a downstream user of InlineCost. I found that upstream SampleProfile uses getInlineCost with ComputeFullInlineCost, so I added a test case demonstrating the issue via SampleProfile.

Yeah, SampleProfile is interested in the cost only as it uses its own threshold based on profiles (we don't rely on the threshold from getInlineCost because profile isn't annotated on IR yet). Actually I added DecidedByCostBenefit and it was also for sample profile case.

This revision was landed with ongoing or failed builds.Oct 14 2021, 5:48 PM
This revision was automatically updated to reflect the committed changes.