https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Severity|normal |enhancement
Last reconfirmed| |2022-02-28
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Vittorio Romeo from comment #6)
> > The request is to replace it with some kind of magic that does the same as
> > std::move without actually writing std::move.
>
> More generally speaking, ensure that function such as `std::move`,
> `std::forward`, `std::vector<T>::operator[]`,
> `std::vector<T>::iterator::operator*`, and so on never appear in debugging
> call stacks and do not affect performance in `-Og` (or even `-O0`.
They will still appear in debugging stacks, because GCC emits debug info even
for inline functions. That means that GDB makes it look like the function was
entered and exited, even if the actual code is completely inlined. That was the
original topic of PR 96780 (because I don't think it's useful for std::move and
std::forward). I think what *should* matters is actual raw performance, not how
many stack frames you see in the debugger. However, reading twitter and reddit,
I think people would complain about insane levels of complexity in the std::lib
*even if it has zero overhead*.
> I think the title for my issue is a bit too specific, but I'd like to make
> this a wider discussion in how to mitigate debug performance overhead caused
> by C++ standard library abstractions.
OK, confirming as an enhancement, but somebody will need to do measurements and
propose specific patches. I'm not aware of any low-hanging fruit for runtime
perf, so the problems need to be identified before they can be fixed.
