[AMDGPU] Use InliningThresholdMultiplier for inline hint

[rampitec]

Summary

AMDGPU uses multiplier 9 for the inline cost. It is taken into account
everywhere except for inline hint threshold. As a result we are penalizing
functions with the inline hint making them less probable to be inlined
than those without the hint. Defaults are 225 for a normal function and
325 for a function with an inline hint. Currently we have effective
threshold 225 * 9 = 2025 for normal functions and just 325 for those with
the hint. That is fixed by this patch.

[arsenm]

Needs test. I'm also not sure I follow how getInliningThresholdMultiplier is used. It looks like it's applied after any of the thresholds are computed in CallAnalyzer::updateThreshold?

Also why do we actually override getInlineThreshold? The alloca object check seems like it shouldn't really be fundamentally different than the SROA checks the default InlineCost does

[rampitec]

In D62707#1524219, @arsenm wrote:

Needs test. I'm also not sure I follow how getInliningThresholdMultiplier is used. It looks like it's applied after any of the thresholds are computed in CallAnalyzer::updateThreshold?

Also why do we actually override getInlineThreshold? The alloca object check seems like it shouldn't really be fundamentally different than the SROA checks the default InlineCost does

I can add test, but it essentially will be a quite large function.
Yes, multiplier is applied in the CallAnalyzer::updateThreshold(), which applies to a normal threshold. But here we handle it ourselves, so need to update.
The primary reason to override getInlineCost() is to handle alloca arguments, but it also handles wrapper calls and used to limit inlining based on the number of blocks.

[arsenm]

In D62707#1524236, @rampitec wrote:

In D62707#1524219, @arsenm wrote:

Needs test. I'm also not sure I follow how getInliningThresholdMultiplier is used. It looks like it's applied after any of the thresholds are computed in CallAnalyzer::updateThreshold?

Also why do we actually override getInlineThreshold? The alloca object check seems like it shouldn't really be fundamentally different than the SROA checks the default InlineCost does

I can add test, but it essentially will be a quite large function.

You can use the flags to make it a small function

[rampitec]

Added test.

[arsenm]

test/CodeGen/AMDGPU/inline-hint.ll

1 ↗

(On Diff #202330)

Can you remove the -O1, and also move to test/Transforms/Inline/AMDGPU

[rampitec]

Removed -O1 and moved test.

[rampitec]

Restored -O1. opt does not run inliner w/o it.

[arsenm]

test/Transforms/Inline/AMDGPU/inline-hint.ll

1 ↗

(On Diff #202337)

You need to replace -O1 with -inline, not just remove it

[rampitec]

Replaced -O1 with -amdgpu-inline.

[arsenm]

LGTM

lib/Target/AMDGPU/AMDGPUInline.cpp

unsigned AMDGPUInliner::getInlineThreshold(CallSite CS) const {
   Function *Caller = CS.getCaller();
   // Listen to the inlinehint attribute when it would increase the threshold
   // and the caller does not need to minimize its size.
   Function *Callee = CS.getCalledFunction();
   bool InlineHint = Callee && !Callee->isDeclaration() &&
     Callee->hasFnAttribute(Attribute::InlineHint);
   if (InlineHint && Params.HintThreshold && Params.HintThreshold > Thres
       && !Caller->hasFnAttribute(Attribute::MinSize))
-    Thres = Params.HintThreshold.getValue();
+    Thres = Params.HintThreshold.getValue() *
+            TTIWP->getTTI(*Callee).getInliningThresholdMultiplier();
 
   const DataLayout &DL = Caller->getParent()->getDataLayout();
   if (!Callee)
     return (unsigned)Thres;
 
   // If we have a pointer to private array passed into a function
   // it will not be optimized out, leaving scratch usage.
   // Increase the inline threshold to allow inliniting in this case.