similar to: [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, >> >> 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

Hi all, This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in: https://reviews.llvm.org/D41675 ). The process that we’re going to use for landing this will take a few steps. To wit: Step 1) Remove align argument, and add align attribute to pointer args. Require that src & dest have the same alignment via verifier rule. Also

Good day all, I’ve spent a few days resurrecting the circa-2015 work on removing the explicit alignment argument (4th arg) from the @llvm.memcpy/memmove/memset intrinsics in favour of using the alignment attribute on the pointer args of calls to the intrinsic. This work was first proposed back in August 2015 by Lang Hames: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html (item

> On Jan 18, 2018, at 7:45 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > Hi all, > This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in: https://reviews.llvm.org/D41675 <https://reviews.llvm.org/D41675> ). The process that we’re going to use for landing this will take a few

On Jan 18, 2018, at 10:48 PM, Chris Lattner <clattner at nondot.org<mailto:clattner at nondot.org>> wrote: On Jan 18, 2018, at 7:45 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi all, This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in:

Hi Daniel, a quick question (and kind-of a follow-up to <https://lists.llvm.org/pipermail/llvm-dev/2017-July/115665.html>): Do the pointers have to be aligned even if the size is 0? It would be nice to have this stated explicitly in the LangRef. Kind regards, Ralf On 26.03.2018 22:43, Daniel Neilson via llvm-dev wrote: > Hi all, >  A quick note just to let people know that as of

On 3 Dec 2014, at 23:36, Robert Lougher <rob.lougher at gmail.com> wrote: > On 2 December 2014 at 22:18, Alex Rosenberg <alexr at leftfield.org> wrote: >> >> Our C library amplifies this problem by being in a dynamic library, so the >> call has additional overhead, which for small trip counts swamps the >> copy/set. >> > > I can't imagine

Hi all, A quick note just to let people know that as of this past Friday my go at this work has been fully landed. It ended up being a back-burner item, so it took longer than I would have liked to get completed. None the less, the changes made were: 1) The IRBuilders in LLVM, Clang, and Polly were all updated to create only the new form of the memory intrinsics. 2) All LLVM passes to understand

Hi all, We currently have code in InstCombine that tries to expand memcpy / memmove intrinsics that are copying something that fits in a single register to a load and store in the IR. We then have other code in SelectionDAG that expands small memcpy intrinsics to sequences of loads and stores. The InstCombine one is useful, as it exposes more optimisation opportunities, but unfortunately it is

Hal, I appreciate the clarification. That was what I was expecting (that the transformation uses intrinsics), Intel compiler does the same thing internally, and like LLVM it is into an internal intrinsic, not a plain library call. Nevertheless, there are a huge number of ways (In machine code) to write "the best" memory copy or memory set sort of code if, as a programmer, you are able

There are a large number of ways to lose information in translating loops into memset/memcpy calls, alignment is one of them. As previously mentioned, loop-trip-count is another. Another is size of accesses. For example, the loop may have originally been using int64_t sized copies. This has definite impact on what the best memset/memcpy expansion is, because effectively, the loop knows that it

As of earlier this year, we now explicitly ignore the nonnull attributes that glibc puts on memcpy (and other stdlib functions). I don't know how LLVM feels about dangling or underaligned pointers in particular, but AFAICT, we do try hard to make sure that memcpy(NULL, _, 0) works as the user probably intends. Here's the thread I read about it:

TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative effect on GC latencies

Hi all, when I call the llvm.memcpy/memmove/memset.* intrinsics, typically I have to pass in valid (non-dangling, non-NULL pointers) of the given alignment. However, to what extent to these rules apply when the count is 0? Concretely (for any variant of the three aforementioned intrinsics): Is it UB to call them on a dangling pointer when count is 0? On a pointer of less than the given

I can't think of a better way to do this, so I think it's ok. I also submitted a complementary patch on llvm-commits clarifying volatile semantics. -Andy On Jan 28, 2013, at 8:54 AM, Arnaud A. de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote: > Hi All, > > In the language reference manual, the access behavior of the memcpy, > memmove and memset

If I copy or set zero bytes with memcpy(), memmove(), or memset(), can the <dest> and <src> arguments be null? Can they be invalid pointers? Regards, Jon