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

[Daniel Neilson via llvm-dev]

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>> 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>
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/20180326/32d23b5b/attachment.html>