[LLVMdev] inlining hint

[Eli Friedman]

On Wed, Aug 26, 2009 at 2:50 PM, Devang Patel<devang.patel at gmail.com> wrote:
> On Wed, Aug 26, 2009 at 1:09 PM, Chris Lattner<clattner at apple.com> wrote:
>
>> I know/hope that the proposal isn't for the inlinehint to be a synonym for
>> "force inline", it would just raise the threshold to increase the likeliness
>> that it would be inlined.
>
> One alternative is to give the functions with hint first chance but
> not change the threshold. Inliner works in two phase. In first phase,
> only use function with inlinehint as candidates.

Truthfully, I think we need a thorough discussion our current inlining
heuristics before we try to consider what  inlinehint adds to the
picture.  The inlining code has been mostly untouched for a very long
time.

Some limitations I can think of off the top of my head:
Inlining doesn't take into account whether a load from a constant
pointer is constant.
Inlining is purely bottom-up: we inline large functions into small
functions when it would be better to inline the small function.
The cost metrics for constant-propagating into a branch or switch are
extremely imprecise.
Cost metrics can easily end up being negative (i.e. we always inline)
in cases where inlining will lead to arbitrarily large increases in
code size.
We only use one inlining pass normally; IIRC, the gcc devs found that
an additional early inlining pass is beneficial.

There are probably other issues which aren't obvious to me because I'm
not an expert in this sort of thing...

-Eli