[llvm-dev] Change memcpy/memmove/memset to have dest and source alignment attributes

Mon Apr 2 09:12:26 PDT 2018

Someone more knowledgable can correct me if I’m wrong here…

 As I understand it the alignment attribute on any pointer argument in a call is telling the compiler something about the alignment of that pointer, and that is all. It doesn’t know/understand/care about anything else about the call.

 So, in the case of memcpy/memmove/memset I would expect that the alignment argument attribute, if you provide one, has to be correct for the value of the pointer argument it is being attached to. I would also expect that whether the memmove/memcpy/memset is doing a 0-length operation or not is entirely immaterial to the alignment of its pointer args.

 As an aside: The alignment attributes on the source/dest of a memcpy/memmove/memset intrinsic are entirely optional.

-Daniel

On Apr 2, 2018, at 10:59 AM, Ralf Jung <post at ralfj.de<mailto:post at ralfj.de>> wrote:

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 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 the new forms of the intrinsics; modulo the
notes below.
3) The IRBuilder APIs for creating the old-style memcpy/memmove/memset forms and
the MemIntrinsicInst API for getting/setting the old generic/conservative
alignment have all been eliminated.

 There are a few places where the LLVM pass updates were conservative, and could
potentially be made more aggressive by a motivated individual — list below.

 All that remains is for interested folk to enhance lowering of small
memcpy/memmove into load/store sequences. The lowering in SelectionDAG currently
just conservatively uses the MinAlign() of the source & dest alignments as the
alignment for the loads and stores. I suspect that we could do better by
teaching the lowering that the source & dest can have different alignments.

 Note that, also, the createMem[Cpy|Move]Loop type functions used in the
LowerMemIntrinsics pass are also now invoked with different source & dest
alignments by LowerMemIntrinsics, rather than the same alignment for both, so
these helpers will now be invoked with more information than they have in the
past; I’m guessing that it’s possible they could do better with this
information. For example, createMemMoveLoop() doesn’t even use the alignments
it’s given at all right now, and the neither of the createMemCpyLoop*()
functions try to set the alignments on the loads & stores it creates.

Passes that have conservative alignments after updating:
- SelectionDAG
- AArch64FastISel
- ARMFastISel
- MemorySanitizer
- MemCpyOpt : Call slot optimization
- InlineFunction :  HandleByValArgumentInit
- LowerMemIntrinsics (see note above)

Cheers,
 Daniel

---
Daniel Neilson, Ph.D.
Azul Systems

On Jan 2, 2018, at 2:11 PM, Daniel Neilson via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org>> wrote:

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 2)
 and an attempt at landing the work was made by Pete Cooper in November 2015,
but then backed out due to unspecified bot failures:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

 I’ve prepared changes for LLVM, Clang, and Polly that are now up for review:
* https://reviews.llvm.org/D41675   (LLVM part)
* https://reviews.llvm.org/D41676   (polly part)
* https://reviews.llvm.org/D41677   (Clang part)

 Importantly for those maintaining downstream users of the LLVM API, this
changes the prototypes for the @llvm.memcpy/memmove/memset intrinsics and
changes the IRBuilder API for creating memcpy and memmove calls.

For example, IR which used to read:
     call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4,
i1 false)
will now read
     call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src,
i32 100, i1 false)

 The LLVM change includes auto upgrade of the old IR. However, match
expressions in IR tests and calls to IRBuilder’s CreateMemCpy & CreateMemMove
will need to be updated.

 My plan is to post another note to the list when the change is landed, and
stable.

 Comments? Concerns?

-Daniel

---
Daniel Neilson, Ph.D.
Azul Systems

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180402/254f1770/attachment-0001.html>