llvm dev - Aug 2009 - [LLVMdev] inlining hint

On Aug 26, 2009, at 11:54 AMPDT, Devang Patel wrote:
> On Wed, Aug 26, 2009 at 10:59 AM, Dale Johannesen<dalej at apple.com>
> wrote:
>> You may have noticed I added an "inlinehint" attribute to the
IR
>> yesterday, to represent user declarations that hint inlining would be
>> a good idea ("inline" keyword).  Chris and I have been
discussing how
>> to hook it up to the C++ FE.  Consider:
>>
>> 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.   I want to get some other views on
>> this.  Do you think it's a good idea?
>> (For those of you who consider yourselves C++ programmers - and not  
>> FE
>> language lawyers, who are supposed to know what the standard says -
>> did you know this?)
>
> 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.

On Wed, Aug 26, 2009 at 11:58 AM, Dale Johannesen<dalej at apple.com>
wrote:
>
> On Aug 26, 2009, at 11:54 AMPDT, Devang Patel wrote:
>
>> On Wed, Aug 26, 2009 at 10:59 AM, Dale Johannesen<dalej at
apple.com> wrote:
>>>
>>> You may have noticed I added an "inlinehint" attribute to
the IR
>>> yesterday, to represent user declarations that hint inlining would
be
>>> a good idea ("inline" keyword).  Chris and I have been
discussing how
>>> to hook it up to the C++ FE.  Consider:
>>>
>>> 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.   I want to get some other views on
>>> this.  Do you think it's a good idea?
>>> (For those of you who consider yourselves C++ programmers - and not
FE
>>> language lawyers, who are supposed to know what the standard says -
>>> did you know this?)
>>
>> 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.
-
Devang

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