[LLVMdev] inlining hint

[David Vandevoorde]

On Aug 26, 2009, at 4:09 PM, Chris Lattner wrote:
[...]
>
> 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.


I don't think those are _good_ reasons though: If one doesn't want a C+ 
+ function to be inlined, one shouldn't define it inline.


>  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 think that's the same issue as above: If you don't think it's a good  
candidate for inlining, it shouldn't be defined inline.


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

	Daveed