https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
Wilco <wdijkstr at arm dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wdijkstr at arm dot com
--- Comment #2 from Wilco <wdijkstr at arm dot com> ---
(In reply to Jakub Jelinek from comment #1)
> These glibc inlines are just wrong, they should trust the compiler doing the
> right thing at least for contemporary versions.
> 05a910f7b420c2b831f35ba90e61c80f001c0606 should be IMHO reverted, it should
> be approached at the compiler side if the ARM folks see any performance
> issues with what is generated.
It's not about the generated code, it's about whether one calls memcpy or
mempcpy in the case where GCC doesn't inline it. Few targets support an
assembler mempcpy implementation, so by default the best option is defer to
memcpy. Targets can add an optimized mempcpy and define
_HAVE_STRING_ARCH_mempcpy to get mempcpy (as x86 does).
Is there a mechanism by which GCC is told accurately whether the library it
targets supports an optimized mempcpy?
