llvm dev - Aug 2009 - [LLVMdev] inlining hint

When I started this, I deliberately restricted the question to what  
should go in the IR.  The fact of recording hints in the IR should not  
be controversial; it can't be better not to have them than to have them.

Unfortunately, others used this as a springboard for discussing  
whether and how the inliner should use those hints.  We aren't really  
ready to have that discussion, because nobody has any data on how well  
that would work in llvm.  (We do have some data on well it worked on  
other compilers; I have worked on 2 others, and ignoring "inline" did
not work well in either.  David Vandevoorde evidently has similar  
experience.)

I should probably comment on this, since nobody seems to get
it:
> Dale comes at this from the premise that the inliner will always  
> make the wrong decision in some cases and therefore it is useful to  
> give the user some way to influence the inliners heuristic (other  
> than attr(noinline/alwaysinline)).
On a theoretical basis, this is not a premise, it is a fact.  Which  
calls it is beneficial to inline depends on which calls get executed.   
The compiler can't know that (barring profile-based feedback), the  
user can.   Any heuristic based on information available to a compiler  
cannot get it right in all cases.  Really, hints and the noinline/ 
alwaysinline attributes are not enough either; users need something  
they can put on individual calls.  It is frequently the case that some  
calls to a function get executed more, and therefore benefit from  
inlining more,  than others.  Perhaps we should make alwaysinline/ 
noinline work on calls.  (There is code around here where users have  
inlined functions by hand, or forced them into macros, because they  
didn't have fine-grained control of the compiler's inlining.  We  
don't  want to encourage either of those practices, I'm sure.)

Now whether user hints can be trusted in practice in real code is,  
evidently, debatable, but I can point to my experience and David  
Vandevoorde's with other compilers as evidence that the theoretical  
considerations apply in practice as well.  (It is also probably true  
that people who declare things inline in C/ObjC should be taken more  
seriously than those using C++; Apple's gcc has an adjustment to the  
inlining parameters that does this, which works well in practice on  
our code.)

Dale Johannesen <dalej at apple.com> writes:

[snip]
> (It is also probably true that people who declare things inline in
> C/ObjC should be taken more seriously than those using C++; Apple's
> gcc has an adjustment to the inlining parameters that does this, which
> works well in practice on our code.)
If the user absolutely wants to inline a function, the `inline' keyword
is no solution. As Nick says on other message, he should use the
alwaysinline attribute.

`inline' as a hint saying "I'll like this to be inlined, but no
hard
feelings if you don't" reflects either a shortcoming on the compiler or
a personality trait on the user. On what scenario it is useful to hint
the compiler about candidates for inlining, instead of requiring it?

OTOH I've seens lots of C++ code where `inline' is used everywhere for
no reason (a lot within class definions). Using it as a hint would
decrease the efficacy of the compiler's heuristics and actually produce
worse code.

-- 
Óscar

Hi Óscar,
> `inline' as a hint saying "I'll like this to be inlined, but
no hard
> feelings if you don't" reflects either a shortcoming on the
compiler or
> a personality trait on the user. On what scenario it is useful to hint
> the compiler about candidates for inlining, instead of requiring it?
the Ada frontend to gcc will do cross-unit inlining, but only if the
inline keyword is present.  In C terms what it does is: when compiling
"a.c", if in an included header file it sees a function declaration F
with the inline keyword, then it finds the file "b.c" in which F is
defined (in Ada it knows where this is), grabs the definition of F out
of "b.c" and (if it thinks it is worthwhile) inlines it into
"a.c".
This is an expensive operation, so it only does it if the inline keyword
is present and the optimization level is high enough (and the feature is
turned on).

Ciao,

Duncan.