[LLVMdev] inlining hint

[Chris Lattner]

On Aug 26, 2009, at 12:01 PM, Devang Patel wrote:
>>> I do not understand how the "inlinehint" will help.  How will it
>>> influence the inliner ?
>>
>> The hint should make it more attractive to inline.  I don't know  
>> the details
>> yet and they will require some experimenting.
>>
>
> In that case you want to add hint to A also. AFAIU, attractiveness of
> A and B should match and inliner won't know whether the function body
> is inside the class definition or not.

For background it is useful to know that a lot of this discussion is  
based on the assumption that the inliner will be making the wrong  
decisions.  Dale comes at this from the premise that the inliner will  
always make the wrong decision and therefore it is useful to give the  
user some way to influence the inliners heuristic (other than  
attr(noinline/alwaysinline)).

There are three questions to consider:
1. whether a function is "semantically inline" should make it more  
attractive to inline.
2. whether a function that is "syntactically inline" should make it  
more attractive to inline.
3. whether neither should matter and the inliner should just look at  
the structure and size of the code, ignoring both syntactic and  
semantic inline hints (But still listening to always and noinline  
attributes of course).

To me personally, I have a hard time believing that either hint is  
really trustworthy and would rather invest effort into seeing how far  
we can get with #3.  My reason for thinking this is twofold: first,  
many people slap the inline keyword on stuff without really thinking  
about how big the code will be.  In the case of C++, because of  
abstraction and other things, the code may be compiled to something  
much larger than the source looks.

The second part of this is that there are a lot of reasons for things  
to be defined inline in C++ even if we don't want it to actually be  
inlined.  For example, lib/VMCore/ConstantsContext.h:349 has  a  
massive inline function that is there because it is part of a template  
specialization and *it is more convenient* to define it inline.  I  
really don't think that method should be inlined, but it makes the  
source code tidier to do that.  There are several other "good"  
examples in that file as well.

Since templates all have to be defined in header files for them to be  
instantiated, we frequently get large functions defined inline even  
though they shouldn't.  One trivial example is  
SmallVector::insert(iterator,size_t, T).

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.  The question is whether  
"something being c++ inline" in any way is really trustworthy, and if  
so, whether we should look at syntactic vs semantic inline.

-Chris