search for: memcpy

I have found that pid provider can not create memcpy:return probe for 64bit process on snv_110. For example, the pid is 10603, I will have following output for dtrace command: #dtrace -n pid10603:libc.so.1:memcpy:return dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return: probe description pid10603:libc.so.1:memcpy:return...

Hi All, I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy...

Hi, My pass scans call instructions for standard C library calls. For some libc functions, however, LLVM uses intrinsics instead. For example, I see that my memcpy calls are replaced by the llvm.memcpy.* intrinsics. This is not a problem because I can simply look for llvm.memcpy calls when scanning for memcpy calls. The problem arises when LLVM implicitly inserts llvm.memcpy intrinsics into my bitcode files when it thinks they are needed. In this case, I do...

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

On 08/19/2015 09:35 AM, Pete Cooper via llvm-dev wrote: > Hey Lang >> On Aug 18, 2015, at 6:04 PM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi All, >> >> I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. >> >> >> (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. >> >> When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (othe...

...ndlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>>>> -ffreestanding >>>>> > with no success. >>>>> clang (as well as gcc) requires that freestanding environment provides >>>>> memcpy, memmove, memset and memcmp. >>>>> >>>>> PS: Consider emailing cfedev, not llvmdev. >>>>> >>>> >>>> Hi, >>>> >>>> Thanks. I've emailed cfe-dev. >>>> We absolutely need clang/llvm to not inse...

...te Cooper" <peter_cooper at apple.com>, "Lang Hames" <lhames at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvm-dev at lists.llvm.org> >> Sent: Wednesday, August 19, 2015 12:14:19 PM >> Subject: Re: [llvm-dev] [RFC] Generalize llvm.memcpy / llvm.memmove intrinsics. >> >> On 08/19/2015 09:35 AM, Pete Cooper via llvm-dev wrote: >>> Hey Lang >>>> On Aug 18, 2015, at 6:04 PM, Lang Hames via llvm-dev >>>> <llvm-dev at lists.llvm.org> wrote: >>>> >>>> Hi All, &gt...

Hi Hal > By this I assume you mean some new 'nooverlap' metadata? I don't think we have any existing metadata with the correct semantics. I was thinking we could just use the existing noalias metadata. Implicitly, the current llvm.memcpy semantics are "src and dst overlap perfectly or not at all" (perhaps we should update the docs to reflect this if we plan to rely on it?). Attaching noalias metadata to the source and destination would capture the extra information that the pointers really do not overlap, when we can figu...

...rote: > >> > How do I disable that feature? I've tried -fno-builtin and/or >>>>>> -ffreestanding >>>>>> > with no success. >>>>>> clang (as well as gcc) requires that freestanding environment provides >>>>>> memcpy, memmove, memset and memcmp. >>>>>> >>>>>> PS: Consider emailing cfedev, not llvmdev. >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> Thanks. I've emailed cfe-dev. >>>>> We absolu...

...ature? I've tried -fno-builtin and/or >>>>>>> > -ffreestanding >>>>>>> > with no success. >>>>>>> clang (as well as gcc) requires that freestanding environment >>>>>>> provides >>>>>>> memcpy, memmove, memset and memcmp. >>>>>>> >>>>>>> PS: Consider emailing cfedev, not llvmdev. >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks. I've emailed cfe-dev. >&g...

+ llvm-dev On 25 Aug 2020, at 13:53, Florian Hahn wrote: > Hi, > > It appears that Clang generates calls to `llvm.memcpy` with > potentially overlapping arguments in some cases. > > For the snippet below > > struct S > { > char s[25]; > }; > > struct S *p; > > void test2() { > ... > foo (&b, 1); > b = a; > b = *p; > ... > } > > > Clang uses...

Pete - That patch sounds great! Philip, Hal, Medhi, Gerolf - Thanks very much for the feedback. So how about this: (1) We drop llvm.memcpy's alignment argument and use Pete's alignment-via-metadata patch (whatever version of it passes review). (2) llvm.memcpy retains its current semantics, but we teach clang, SimplifyLibCalls, etc. to add noalias metadata where we know it's safe. Dropping the alignment argument will still...

Usage of the builtin appears independent of LTO, see below. With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which are all typically used to prevent usage of memcpy calls, we still always get a memcpy builtin in TlsDriverEntryPoint(). I see this even without -flto (e.g. try with just -emit-llvm). I guess it is because this memcpy is not coming from the original source, but rather fro...

Hi Hal, > If you attach noalias metadata to the memcpy call, it will apply to both the source and destination; we don't have a way to differentiate. It might be true that if you attach both noalias and alias.scope metadata to the call, then querying the call against itself will return NoModRef, but that's really hacky (and, in part, wrong, beca...

...> > "/home/jshi19/llvm/llvm-project/releaseinstall/bin/clang" -Oz -flto > -target i686-unknown-windows -fno-builtin -c -o main.obj main.c > > "/home/jshi19/llvm/llvm-project/releaseinstall/bin/clang" -Oz -flto > -target i686-unknown-windows -fno-builtin -c -o memcpy.obj memcpy.c > > "/home/jshi19/llvm/llvm-project/releaseinstall/bin/llvm-lib" > /OUT:main.lib main.obj > > "/home/jshi19/llvm/llvm-project/releaseinstall/bin/llvm-lib" > /OUT:memcpy.lib memcpy.obj > > "/home/jshi19/llvm/llvm-project/releaseinstall/b...

...o-builtin and/or > >>>>>>> > -ffreestanding > >>>>>>> > with no success. > >>>>>>> clang (as well as gcc) requires that freestanding environment > >>>>>>> provides > >>>>>>> memcpy, memmove, memset and memcmp. > >>>>>>> > >>>>>>> PS: Consider emailing cfedev, not llvmdev. > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Thank...

Hello, I'm getting the impression that I'm misunderstanding something about intrinsics. I have the following reduced testcase in mind: declare void @llvm.memcpy.i32(i8*, i8*, i32, i32) nounwind define void @foo(i8* %a, i8* %b, i32 %c, i32 %d) { entry: ;call void @llvm.memcpy.i32( i8* %a, i8* %b, i32 %c, i32 %d ) ;call void @llvm.memcpy.i32( i8* %a, i8* %b, i32 0, i32 0 ) ret void } I compile this with llvm-as memcpy-intrinsic.ll -f -o memcpy-intri...

lld should not crash in this case (so that's a bug that needs fixing), but setting it aside, did you try adding `-fno-builtin` to clang so that clang doesn't handle `memcpy` as a built-in function? On Tue, Jul 16, 2019 at 8:46 PM Shi, Steven <steven.shi at intel.com> wrote: > Hi Rui, > > For the test case in my previous email, if I change the `memcpy` to > `foobar` in memcpy.c, the lld-link report linking error that it cannot find > the _memcpy...

...at feature? I've tried -fno-builtin and/or >>>>>>> -ffreestanding >>>>>>> > with no success. >>>>>>> clang (as well as gcc) requires that freestanding environment >>>>>>> provides >>>>>>> memcpy, memmove, memset and memcmp. >>>>>>> >>>>>>> PS: Consider emailing cfedev, not llvmdev. >>>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks. I've emailed cfe-dev. &g...

Hi Steven, One thing I noticed is that you are defining `memcpy`, which clang has an intrinsic with the same name. Can you try renaming it to a random name, like `foobar`, to see if the problem still exists? On Tue, Jul 16, 2019 at 10:10 AM Shi, Steven <steven.shi at intel.com> wrote: > I’ve submitted a BZ for this issue as below: > > > >...