search for: structcpi

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

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

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.

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

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