This is the mail archive of the
mailing list for the glibc project.
[Bug string/25131] memcpy perfomance problem with ARM 32 A9be due to high cache-misses
- From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 25 Nov 2019 13:47:42 +0000
- Subject: [Bug string/25131] memcpy perfomance problem with ARM 32 A9be due to high cache-misses
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #12 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
ARMv7 on glibc now uses three different implementations selected at runtime
using the hwcap. They are selected by:
They all build from the same source
however with different compiler flags. They are:
(Note that __memcpy_arm only is build if compiler is targeting a softfp).
And some implementation are built whether the compiler support softfp or not.
ARM uses the old armv5 implementation set as default at:
So the resulting implementation to be used at runtime depends on *who* glibc
was build along which hwcap bits kernel advertise. In a short:
- The default memcpy will be if either gcc used to build glibc defined
__ARM_ARCH_6T2__ or older (set by -march=).
- The armv7 ifunc one will be used if compiler defines __ARM_ARCH_7A__
(-march=armv7-a or newer).
- The default memcpy will be also used if glibc build configured with
--disable-multi-arch (which disable ifunc selectors).
So my suggestion would be to evaluate __memcpy_neon, __memcpy_vfp,
__memcpy_arm, and the default implementation (either by rebuilding glibc or
*NOTE*: there is a bug on master after 1673ba87fefe019c that configuring for
armv7 does not enable multiarch support. I am working on fixing it.
You are receiving this mail because:
You are on the CC list for the bug.