[llvm-dev] [RFC] Target-specific parametrization of function inliner

Hal Finkel via llvm-dev
Thu, 10 Mar 2016 14:42:36 -0000

----- Original Message -----
> From: "Artem Belevich via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, March 1, 2016 6:31:06 PM
> Subject: [llvm-dev] [RFC] Target-specific parametrization of function
inliner
>
> Hi,
>
>
> I propose to make function inliner parameters adjustable for specific
> target.
>
> Currently function inlining pass appears to be target-agnostic with
> various constants for calculating call cost hardcoded. While it
> works reasonably well for general purpose CPUs, some quirkier
> targets like NVPTX would benefit from target-specific tuning.
>
>
> Currently it appears that there are two things that need to be done:
>
>
> * add Inliner preferences to TargetTransformInfo in a way similar to
> how we customize loop unrolling. Use it to provide inliner with
> target-specific thresholds and other parameters.
> * augment Inliner pass to use existing TargetTransformInfo API to
> figure out cost of particular call on a given target.
> TargetTransforInfo already has getCallCost(), though it does not
> look like anything uses it.
>
>
> Comments? Concerns? Suggestions?
>

Hi Art,

I've long thought that we should have a more principled way of doing inline
profitability. There is obviously some cost to executing a function body, some
call site overhead, and some cost reduction associated with any post-inlining
simplifications. If inlining reduces the overall call site cost by more than
some factor, say 1% (this should probably depend on the optimization level),
then we should inline. With profiling information, we might even use global
speedup instead of local speedup.

Whether we need a target customization of this threshold, or just a way for a
target to supplement the fine inlining decision, is unclear to me. It is also
true that a the result of a bunch of locally-optimal decisions might be far from
the global optimum. Maybe the target has something to say about that?

In short, I'm fine with what you're proposing, but to the extent
possible, I want the numbers provided by the target to mean something. Replacing
a global set of somewhat-arbitrary magic numbers, with target-specific sets of
somewhat-arbitrary magic numbers should be our last choice.

Thanks again,
Hal


>
> Thanks,
> --
>
>
> --Artem Belevich
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory