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

[Ralf Jung via llvm-dev]

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>> 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
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>