I am working on project that is currently build with gcc and run-times based on newlib 4.3.0.

As an experiment to see if we can reduce link time I am trying out a clang compile linked with lld thin lto. So far so good link time is reduced but run-time performance of my target has become worse with clang.
Clang run-times same as gcc are also based on newlib 4.3.0.

By debugging and comparing my gcc builds with my clang builds I have observed that my clang builds, pick the “wrong” memcpy i.e. clang picks the function named libc_a-aeabi_memcpy-armv7a.o whereas gcc picks the function named libc_a-memcpy-armv7a.o. Via llvm-objdump I can see that libc.a contains both implementations.

aeabi_memcpy-armv7a, seems to be a version of memcpy optimized for arm with hard floating point support. As such one should think this is the right pick but it is actually slower than the one that gcc picks since it does not use the the vectorization instructions that the arm hard floating point unit/ co-processor allows for?

When I compile for both gcc and clang I use the options -mthumb -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=neon -munaligned-access.
I.e. basically I am telling the cpu and fpu I have which should then make clang pick the right optimized version of memcpy in newlib. Except it picks the wrong one?

Shouldn’t setting up the cpu and fpu be enough to tell clang that is can pick the “right” memcpy?
Where the “right” memcpy is the one that actually uses the hard floating point unit my cortex-a9 actually has, same as gcc does.

Anyways somehow clang does not pick the “right” memcpy, my question therefore pertains what am I doing that makes clang choose the “wrong” aeabi_memcpy? How clang picks it I have not been able to figure out since libc.a contains both implementations it must pick it somehow and map it to the user, but how eludes me.

Here are some details on the placement of the memcpy functions that come into place in above:
libc (newlib 4.3.0)

newlib-cygwinnewliblibcmachinearmmemcpy-armv7a.S
Uses vectorization i.e. hard floating point co-processor.
This is the “right” faster one pick by gcc in my gcc builds.
newlib-cygwinnewliblibcmachinearmaeabi_memcpy-armv7a.S
Does NOT use vectorization
This is the “wrong” slower one picked by clang in my clang builds.
Hope someone can help me figure out what I am doing wrong or shine some light one where clang picks the right version of the memcpy for the processor setup in question

newlib-cygwinnewliblibcmachinearmmemcpy-armv7a.S is the one that includes the “right” memcpy-armv7a.S. Below I have included memcpy-armv7a.S.
To debug if the macroes __ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == ‘A’ && defined(__ARM_FEATURE_UNALIGNED) are true, I have tried to introduce a compile error. This checks out which also aligns with the llvm-objdump of libc.a that contains both implementations.

#include “arm-acle-compat.h”

#if defined (OPTIMIZE_SIZE) || defined (PREFER_SIZE_OVER_SPEED)
/* Defined in memcpy-stub.c. */

#elif (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == ‘A’
&& defined (__ARM_FEATURE_UNALIGNED))
todo_memcpy_armv7a_was_included //temp compile error to determine if above are defined
#include “memcpy-armv7a.S”

#elif __ARM_ARCH_ISA_THUMB == 2 && !__ARM_ARCH_ISA_ARM
#include “memcpy-armv7m.S”

#else
/* Defined in memcpy-stub.c. */

#endif

Since llvm-objdump of libc.a contains both implementations it must be clang that somehow creates the right alias for mempcy, I just havn’t been able figure out if this is right or where it specifically does it.

I have also generated a map file the project I am compiling, the map file shows that aeabi_memcpy-armv7a.S is used, I expected it to be memcpy-armv7m.S:
1156bc 1156bc 208 4 C:toolsllvm-project18.1.3.B1.03062024bin..libclang-runtimes/arm-none-eabi/armv7a_thumb_hard_neon_exn_rttiliblibc.a(libc_a-aeabi_memcpy-armv7a.o):(.text)
1156bc 1156bc 0 1 $a.0
1156bc 1156bc 0 1 __aeabi_memcpy
1156dc 1156dc 0 1 word_aligned
1156fc 1156fc 0 1 two_word_aligned
11574c 11574c 0 1 copy_less_than_64
115764 115764 0 1 copy_less_than_8
11577c 11577c 0 1 copy_less_than_4
1157a0 1157a0 0 1 return
1157a8 1157a8 0 1 dst_not_word_aligned
1157d8 1157d8 0 1 src_not_word_aligned
11588c 11588c 0 1 __aeabi_memcpy4
1158a0 1158a0 0 1 __aeabi_memcpy8