https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |mkretz at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-12-09
--- Comment #1 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
All of these omissions where actually conscious choices. I had hoped the
compiler would make the right choice about inlining in these cases, because I
can think of uses of stdx::simd where inlining these functions would not be
optimal.
However, if the compiler decides against inlining, the result can potentially
exhibit catastrophic performance, like you experienced. This defeats the
purpose of the type and makes using it a liability. You don't have to fear for
`int * int` to ever turn into a function call either. So going forward I'll
adjust the always_inline policy for simd to follow:
"simd is like a builtin type. Primary operations (i.e. not math functions,
etc.) are never function calls. This is independent of element type and ABI
tag."
The consequence is, that, like for builtin types, the user must consider how to
split large functions into smaller ones.
