This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug string/25131] memcpy perfomance problem with ARM 32 A9be due to high cache-misses

--- 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
using LD_HWCAP_MASK).  

*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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]