[libcxx-commits] [libcxx] [libc++] Mark __{emplace, push}_back_slow_path as noinline (PR #94379)

[via libcxx-commits]

gerben-stavenga wrote:

> My tendency here is to trust the compiler. The example output on the code presented in the bug may seem silly, but why wouldn't the compiler inline there? It's the only function in a translation unit, and it contains a couple of lines. I wonder under what circumstances the compiler chooses to not inline the code.

My point is that the code is wrongheaded. Either the compiler inlines everything and enormous bloat is caused, and if it decides not to inline performance in useful cases drops like a rock. The code should be written that the performance of the fast path is superior independent of the inline/outline decisions.

> 
> However, when we prevent the compiler from inlining, we prevent it from optimizing away dead code.
> 
> Before you change, this silly example is optimized away.
> 
> ```c++
> void foo() {
>     std::vector<int> v;
>     v.push_back(42);
> }
Yes due to the special nature of the new/delete functions the compiler could do this with full inlining. I don't think the side effect free no-ops are that important. I think for stdlib cases outline functions could be annotated with some kind of alloc/realloc/free attributes that similar transformations could still happen, but in the end not all that important for actual code.


https://github.com/llvm/llvm-project/pull/94379