[PATCH] D15401: Refactor threshold computation for inline cost analysis

[Xinliang David Li via llvm-commits]

On Wed, Dec 16, 2015 at 3:13 PM, Easwaran Raman <eraman at google.com> wrote:
> eraman added a comment.
>
>
>
>> I'm just suggesting changing the *APIs* to deal in symbolic settings. Clearly the flag will be numeric. I'm suggested sinking the inline threshold flag into the inline cost analysis completely.
>
>
> I attempted to do that and hit an issue. InlineSimple.cpp provides a createFunctionInliningPass((int Threshold) API. To sink thresholds to InlineCost, this needs to be removed, but this is called by LLVMPassManagerBuilderUseInlinerWithThreshold which is exposed by the llvm-c API

In previous review comments, I mentioned I like to remove threshold
from getInlineCost interfaces -- so I really like Chandler's
suggestion of using symbolic hints to the interface:

... ICA->getInlineCost(CS, OptSize|MinSize|OptSpeed|MaxSpeed);

With symbolic settings, the underlying implementation can actually
overload the meaning of 'cost' -- for instance when optimize for size,
it really means size cost while it can also mean runtime cost (reg
pressure, icache pressure etc) when optimized for speed.

Regarding legacy uses of llvm-c API that depend on threshold, I think
we can provide a backdoor interface for it: When the inliner pass is
created with the threshold, the inliner can pass the threshold around
to ICA, and getInlineCost can be called with a special symbolic value
-- UserSpecified

ICA->getInlineCost(CS, UserSpecified);

Does that make sense?

David

>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D15401
>
>
>