[LLVMdev] inlining hint

[Chris Lattner]

On Aug 26, 2009, at 7:02 PM, David Vandevoorde wrote:
>> 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++)?

That is what is unclear.  We have no empirical evidence that listening  
to inline will improve the situation more than just increasing the  
inlining threshold across the board.  Even if we did, I would still be  
uncomfortable with this: "hasn't been proven entirely competitive yet"  
implies that we've pursued the current inliner and tried hard to make  
it better without listening to inline.  In fact, the current inliner  
is almost completely untuned and has many known problems.

I am concerned that "listening to inline" will paper over other things  
that could be solved in much better ways.  If the inlining heuristics  
were already considered to be well tuned and a study showed that  
'listening to inline' was better than increasing the threshold, then  
I'd be a believer.

I am also much more pessimistic about the world's C++ code than some.   
It turns out that not all c++ programmers are totally awesome :)

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

LLVM already does that at -O1 without listening to inline because the  
code is obviously smaller with the inline.

-Chris