Would it make sense to use __attribute__ ((noinline)) for functions like _M_realloc_insert?

[Marc Glisse]

On Fri, 21 Aug 2020, Groke, Paul via Libstdc++ wrote:

> I've recently noticed that GCC is inlining vector::_M_realloc_insert 
> into some of my functions that call vector::emplace_back.

Could you share which version of gcc you are testing with, what flags you 
are using, and ideally even some code to reproduce this? With current gcc, 
I don't see that happening very often.

> IMO that doesn't make a lot of sense - reallocation is usually so 
> expensive that an extra function call doesn't really matter. And it 
> bloats the code, which has two drawbacks: the binary gets bigger and the 
> fast path gets slower (less efficient pre-fetching/more cache 
> thrashing).
>
> What do you think about marking such functions __attribute__ ((noinline))?

That's a possibility, but I'd rather avoid it if possible. If someone 
inserts an element in a newly created vector, it does make sense to inline 
_M_realloc_insert, especially if we want any hope of making some small 
local vectors use the stack, or removing some unused small vectors.

Ideally, the inliner would already be clever enough not to inline the 
function except in special cases. It is rather large, calls other 
functions, is called with low probability (gcc guesses it as 17% on a 
simple example, using profile guided optimization would lower that number 
if the vectors are usually large), etc. This code isn't doing anything 
unusual (not like std::function or std::any), if the inliner behaves badly 
there, maybe a heuristic needs some tweaking.

> In our own code, we've seen measurable improvements (size & execution speed) by splitting the "slow path" out into helper functions and making those helper functions noinline.

Yes, that's a common strategy, and it would indeed be good to make sure 
that gcc does the right thing for std::vector.

> (I've also noticed that there's no __builtin_expect for the fast path, but that's a different topic and IMO far less important.)

Inlining takes probabilities into account, so this may be strongly 
related. However, gcc already guesses that the fast path is the most 
likely one, it isn't clear that making the probability of the slow path 
too low is a good idea.

Does profile-guided optimization help with your application?

-- 
Marc Glisse