Displaying 6 results from an estimated 6 matches for "mymemcpy".
2014 Aug 05
2
[LLVMdev] Prevent clang from replacing code with library calls
...-arm-enable-ehabi -backend-option
> -arm-enable-ehabi-descriptors -backend-option -arm-ignore-has-ras
> -internal-isystem
> /usr/share/android-arm-l14-toolchain/lib/clang/3.1/include
> -internal-externc-isystem
> /usr/share/android-arm-l14-toolchain/bin/../sysroot/usr/include -o
> myMemcpy.s -x c myMemcpy.c
>
>
> Is there a flag or some other way to prevent the compiler from replacing
> the code with library calls?
>
>
> Thanks in advance,
> David
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at c...
2014 Aug 04
2
[LLVMdev] Prevent clang from replacing code with library calls
...-cpu arm1022e
-backend-option -arm-enable-ehabi -backend-option
-arm-enable-ehabi-descriptors -backend-option -arm-ignore-has-ras
-internal-isystem
/usr/share/android-arm-l14-toolchain/lib/clang/3.1/include
-internal-externc-isystem
/usr/share/android-arm-l14-toolchain/bin/../sysroot/usr/include -o
myMemcpy.s -x c myMemcpy.c
Is there a flag or some other way to prevent the compiler from replacing
the code with library calls?
Thanks in advance,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140804/0caf...
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 apple.com> wrote:
&g...
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.
> It's not broken. Even freestanding implementation is supposed to
> provide mem* functions.
>
It’s also supposed to be p...
2008 Apr 21
0
[LLVMdev] Small problem with intrinsics
...ithout utterly breaking its semantics.
The only safe course is to exclude call or invoke instructions where
getIntrinsicID() != 0 from your transformation. For intrinsics that
you do recognize, you can special-case them. In this case, you can do
the equivalent of:
template <int align>
mymemcpy(...) {
@llvm.memcpy(..., align);
}
— Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080421/3dc250ec/attachment.html>
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