[LLVMdev] inlining hint

[David Vandevoorde]

On Aug 26, 2009, at 6:57 PM, Evan Cheng wrote:

>
> On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote:
>
>>
>>
>>> 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.
>>
>>
>> FWIW, I've been involved in a couple of attempts by commercial
>> compilers to relegate "inline" to the same status as "register" -- an
>> obsolete hint ignored by the compiler -- and so far that always  
>> proved
>> to be unpractical because some critical calls that were previously
>> inlined were no longer being inlined after the change.  (That's just
>> annecdotal, of course: LLVM may have gotten good enough to make it
>> practical.  If that's the case, I still think it's too early to
>> write C
>> ++ code with that assumption.)
>
> It's actually the other way around. llvm has always ignored the
> "inline" keyword and now we are finding out we are missing some
> important cases.


Okay.  It's the "other way around" in terms of history, but it looks  
like the conclusion might be the same: Purely heuristics-based  
inlining hasn't been proven entirely competitive yet (for C++)?

I read in your reply to Eli Friedman that there previously was another  
inliner (part of GCC) that presumably did take the C++ inline property  
into account?  In at least two of the cases I was involved in, the  
scenario was similar: Really dumb "front end" inliners (that only  
inlined inline functions) ended up making a difference that couldn't  
be absorbed by improvements in the back end inliner (within the  
resource/schedule constraints of those subprojects).


> Obviously the only correct solution is to make the inliner smarter so
> it can identify cases which are profitable that's currently ignoring.


Is that really obvious?  It would be nice to have such a correct  
solution, but I'm not positive there exists one.  (There may be just  
as there turned out to be for register allocators -- I'm just not sure.)


> No one is arguing against that. On the other hand, that is most
> definitely not a simple solution. So we need an intermediate step.
>
> The current plan is to make it behave a bit more like gcc (yeah I know
> it's not exactly where we want to go) so the "inline" keyword only
> impacts -O2 compilation. We should make conservative changes and then
> re-evaluate once we have more data. That means people who use llvm to
> compile C++ programs should definitely report any kind of performance
> changes once this change goes into effect.


My GCC installation here appears to inline g in the following example:

	inline int g(int x) { return x; }

	int main() {
	        return g(3);
	}

with just "-O1", but it doesn't do so when I drop the "inline" keyword.

$ g++ --version
g++43 (GCC) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

FWIW,

	Daveed