[LLVMdev] inlining hint

[Török Edwin]

On 2009-08-28 02:02, Reid Kleckner wrote:
> On Thu, Aug 27, 2009 at 6:00 PM, David Greene<dag at cray.com> wrote:
>   
>> On Wednesday 26 August 2009 12:59, Dale Johannesen wrote:
>>
>>     
>>> class X {
>>>     int A(int x) {....}
>>>     inline int B(int x);
>>> };
>>> inline int X::B(int x) {...}
>>>
>>> Per the language standard, A and B are semantically identical, both
>>> "inline".  It's been suggested that we should omit the inlinehint on
>>> A, on the grounds that many C++ programmers do not know this, and
>>> therefore misuse the construct.
>>>       
>> No, no, no!  :)  I rely on this behavior.  I assume anything I define
>> in the class definition will be inlined (when reasonable).  I do this for
>> performance reasons.
>>     
>
> I would say that I am a new and inexpert C++ programmer, and I always
> thought the idea of putting methods in headers was not a way of saying
> to the compiler "please inline this" but rather a way to expose it to
> the compiler so that it would be possible to inline.  When writing
> templates or helper classes, I've always written the methods inline in
> the class definition because it creates less duplication.  If you're
> coming from Java, this style is of course natural.
>
> So to answer Dale's original question, I would guess that most
> inexpert C++ programmers expect that if they define a method inline,
> then they are not telling the compiler it should be inlined, but that
> the compiler should use its heuristics to decide if it should be.

Perhaps there should be an additional inlining pass that first looks at
the hints,
and inlines those functions if heuristics say its feasable, and then do
another
inlining pass and look at the other functions?

I'm not sure that bottom-up is the best choice when there is inline
keyword hint, consider this case:
inline int foo(int cond, int a, int *b) {
  if (cond) {
       *b = 1;
       return a*42;
   }
   return slowpath(cond, a, b);
}

If slowpath is a function just below the inline limit, the inliner might
inline it, and reach the inline limit on foo(), and not inline foo,
despite the hint.
However one might argue that the  user placed the inline hint on foo()
to tell the compiler to inline the call to foo, and not the one to slowpath,
because slowpath should stay a call, since its rarely called. Of course
the user should have also placed noinline on slowpath in that case,
but that is a gcc extension.
In this case I think doing the separate inlining pass for the functions
with the inline hint only could help, although if foo is called by an inline
function itself, then one should use some heuristics to determine which
is more profitable to inline: foo or bar? (assuming that inlining bar would
exceed the threshold for foo).

Also I've seen a partial inliner being worked on in LLVM, which inlines
if statements surrounding function bodies.
Perhaps the partial inliner could be taught to be smarter, and handle
cases like:
 .. small code ... if (cond) { ... small code ... } else { ... huge code
... }, and inline the if+small code, and create a function call for the
else part.
It could give preference to functions with the inline hint.

But back to the original question: an inline hint in the IR certainly
has its advantages, even if we can't agree on how it should be used.

Best regards,
--Edwin