[LLVMdev] inlining hint

[Dale Johannesen]

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.)