search for: memcpi

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 does not match any probes This just

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 prohibits partial overlap). While the C

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

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

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

On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc 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.

> On Aug 19, 2015, at 12:01 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Pete Cooper" <peter_cooper at apple.com>, "Lang Hames" <lhames at gmail.com> >> Cc: "LLVM Developers Mailing

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

On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc 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)

On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: >> >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com> >> wrote: >>>>>>> >>>>>>> > How do I disable that feature? I've

+ 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; > ...

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.

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

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, because the destination still alias with

Yeah, it crashes indeed. I can reproduce the problem locally. Let me see what is going on. On Tue, Jul 16, 2019 at 9:00 PM Shi, Steven <steven.shi at intel.com> wrote: > In my previous test case, after add the `-fno-builtin` to clang then > build, the lld-link still has same crash as below: > > > > $ make > >

On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <jyasskin at googlers.com>wrote: > On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> > wrote: > >> > >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com >

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

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

On Tue, May 29, 2012 at 9:50 PM, Chandler Carruth <chandlerc 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

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: > > > > Bug 42626 - lld-link crash when