search for: __aeabi_memcpy

Hello, I recognized that compiler-rt's the implementation of __aeabi_memcpy simply branches to memcpy. The implementation of memcpy is not provided. So an externally provided memcpy () has to be used. (also applies to memmove, memset, memclr) On ARM I have seen implementations of memcpy () using floating-point registers (if compiled with NEON support). The is perfectly...

On 11 April 2016 at 02:43, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > This is standard AAPCS, I trully hope neither glibc, newlib or musl's > implementations will corrupt anything more. Normal AAPCS functions are allowed to corrupt d0-d7 and d16-d31, but the RTABI seems pretty explicit that these functions aren't. I think we've got a real problem here.

Hi, all I used Clang to compile an ARM-v6m project. The runtime library is from GNU-ARM. But as I used 'memcpy' function, an error 'undefined reference to `__aeabi_memcpy' was emitted by linker. Does it mean that I must use LLVM compiler-RT instead? Thanks a lot. -------------- Steven ***************************** Legal Disclaimer ***************************** "This email may contain confidential and privileged material for the sole use of the intended re...

Clang optimizes code by replacing some parts with efficient library functions. For example the following code: for (i=0;i<size;++i) dest[i]=src[i]; will be compiled to (target=ARM assembly): bl __aeabi_memcpy(PLT) The compile cmd: /usr/share/android-arm-l14-toolchain/bin/clang31 -cc1 -triple arm-none-linux-androideabi -S -target-abi aapcs-linux -target-cpu arm1022e -backend-option -arm-enable-ehabi -backend-option -arm-enable-ehabi-descriptors -backend-option -arm-ignore-has-ras -internal-isystem /usr...

....david at gmail.com> wrote: > > Clang optimizes code by replacing some parts with efficient library > functions. > > For example the following code: > > for (i=0;i<size;++i) > dest[i]=src[i]; > > will be compiled to (target=ARM assembly): > > bl __aeabi_memcpy(PLT) > > The compile cmd: > > /usr/share/android-arm-l14-toolchain/bin/clang31 -cc1 -triple > arm-none-linux-androideabi -S -target-abi aapcs-linux -target-cpu arm1022e > -backend-option -arm-enable-ehabi -backend-option > -arm-enable-ehabi-descriptors -backend-option -arm-igno...

I'm trying to understand why using a local memcpy with LTO results in a "multiple definition" error. I have an local (optimized) mempy.c (clearly simplified!): void* memcpy(void* dest, const void* src, unsigned int count) { return 0; } void* __aeabi_memcpy(void *dest, const void *src, unsigned int size) { return memcpy(dest,src,size); } --- I also have a simple main.c to test it out (also simplified): #include <stdio.h> #include <string.h> struct { char name[40]; } person; char myname[] = "abcd"; int mai...

...wrote: > > Not sure why it's called TargetLibraryInfo if it's not in target specific > > code? It seems that ALL targets use this code, making it generic. Am I > > missing something here? > > Some of the names can vary by platform, for example ARM sometimes has > __aeabi_memcpy instead of memcpy > > > ps. The spec also states (albeit unclearly) that you can use "#undef" to > > omit a library function so that a user defined function of the same name > can > > be used but LLVM doesn't seem to support that. > > I think it says exac...

In the first code I see a 'tail call @acos', in the second code I see a tail call @llvm.acos.f32'. (sorry, there should be only one input for acos, I've been trying many libm/libc functions). Not sure why it's called TargetLibraryInfo if it's not in target specific code? It seems that ALL targets use this code, making it generic. Am I missing something here? Basically

I need to correct myself. It is possible to cross compile it on Windows, but not using the provided build systems. On Sun, Mar 29, 2015 at 12:52 PM, Daniel Dilts <diltsman at gmail.com> wrote: > I asked about this same question in the past (month or three ago). It is > not possible to cross compile compiler-rt on Windows. If you want to cross > compile you should use the make

...t triple, which is usually not OK in a "generic" analysis. If you look in TargetLibraryInfo.cpp, there are various checks for function availability, usually predicated on OS versions. -Ahmed >>> Some of the names can vary by platform, for example ARM sometimes has >>> __aeabi_memcpy instead of memcpy >>> >>> > ps. The spec also states (albeit unclearly) that you can use "#undef" >>> > to >>> > omit a library function so that a user defined function of the same >>> > name can >>> > be used but LLVM d...

...OS versions. >> >> >> >> >> >> -Ahmed >> >> >> >> >> >> >>> Some of the names can vary by platform, for example ARM >> sometimes >> >> >> >>> has >> >> >> >>> __aeabi_memcpy instead of memcpy >> >> >> >>> >> >> >> >>> > ps. The spec also states (albeit unclearly) that you can use >> >> >> >>> > "#undef" >> >> >> >>> > to >> >> >&...

...Clang optimizes code by replacing some parts with efficient library >> functions. >> >> For example the following code: >> >> for (i=0;i<size;++i) >> dest[i]=src[i]; >> >> will be compiled to (target=ARM assembly): >> >> bl __aeabi_memcpy(PLT) >> >> The compile cmd: >> >> /usr/share/android-arm-l14-toolchain/bin/clang31 -cc1 -triple >> arm-none-linux-androideabi -S -target-abi aapcs-linux -target-cpu arm1022e >> -backend-option -arm-enable-ehabi -backend-option >> -arm-enable-ehabi-descripto...

...latform/ > clang_linux.mk and the compiler_rt/make/platform/clang_macho_embedded.mk. > So far it could cross-compile all of the files in > "compiler-rt/lib/builtins/" (*.c files). However, the libcompiler_rt.a > still missing functions such as "__aeabi_memset", "__aeabi_memcpy". These > functions were in "compiler_rt/lib/biltins/arm/" (*.S) files. They are not > included in any of the *.mk files. Do you have any idea on how to add these > assembly sources to the build list? BTW, did you build the complete > libcompiler_rt.a at the end? > &gt...