Displaying 6 results from an estimated 6 matches for "mymemcpi".
Did you mean:
mymemcpy
2014 Aug 05
2
[LLVMdev] Prevent clang from replacing code with library calls
Hi Jim,
I have tried "-fno-builtin" but it didn't help.
Thanks,
David
On Tue, Aug 5, 2014 at 12:12 AM, Jim Grosbach <grosbach at apple.com> wrote:
> Hi David,
>
> "-fno-builtin” is probably what you want.
>
> -Jim
>
> On Aug 4, 2014, at 2:19 AM, David Sela <sela.david at gmail.com> wrote:
>
> Clang optimizes code by replacing some parts
2014 Aug 04
2
[LLVMdev] Prevent clang from replacing code with library calls
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
2014 Aug 07
2
[LLVMdev] Prevent clang from replacing code with library calls
Hi,
I downloaded the latest NDK (r10) and compiled with the following cmd:
*arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0*
It still produces assembly with a call to "memcpy". Maybe the -*fno-builtin
*is broken also in the latest release.
Do you have some other idea that can help here?
Thanks,
David
On Tue, Aug 5, 2014 at 11:00 AM, Jim Grosbach <grosbach at
2014 Aug 07
2
[LLVMdev] Prevent clang from replacing code with library calls
> On Aug 7, 2014, at 4:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote:
>
>> I downloaded the latest NDK (r10) and compiled with the following cmd:
>> arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0
>> It still produces assembly with a call to "memcpy". Maybe the -fno-builtin
>> is broken also in the latest release.
>
2008 Apr 21
0
[LLVMdev] Small problem with intrinsics
On Apr 21, 2008, at 13:00, Bart Coppens wrote:
> Hi Nicolas,
>
>> I guess that's because the value of the last argument of
>> llvm.memcpy hasto be known at compile time.
>
> Hmmm ok, that's understandable, but it's also a bit of a problem for
> me. I am writing a pass that creates a 'shadow' copy of each
> function, so that I can do some
2008 Apr 21
2
[LLVMdev] Small problem with intrinsics
Hi Nicolas,
> I guess that's because the value of the last argument of llvm.memcpy has
> to be known at compile time.
Hmmm ok, that's understandable, but it's also a bit of a problem for me. I am
writing a pass that creates a 'shadow' copy of each function, so that I can
do some bookkeeping with it, and then call the original function afterwards.
This would include