[LLVMdev] inlining hint

[Evan Cheng]

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.

Obviously the only correct solution is to make the inliner smarter so  
it can identify cases which are profitable that's currently ignoring.  
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.

Evan

>
> 	Daveed
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev