Page MenuHomePhabricator

[AArch64FastISel] Replace deprecated calls to MemoryIntrinsic::getAlignment() (NFCI)

Authored by dneilson on Feb 1 2018, 2:03 PM.



This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes
AArch64FastISel to cease using the old getAlignment() API of MemoryIntrinsic in favour of getting
source & dest specific alignments through the new API.

Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, r323891 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.


Diff Detail

Event Timeline

dneilson created this revision.Feb 1 2018, 2:03 PM
dneilson added inline comments.Feb 1 2018, 9:40 PM

I really don't know anything about AArch64; hence why I created a review for such a seemingly trivial change. Is this FIXME accurate on AArch64? i.e. Is there any value in knowing both the source & destination alignments when generating inlined tiny memcpy code sequences?


Again, I really don't know anything about AArch64. This preserves the current behaviour -- this code is equivalent to what already exists. Would it be better to, say, only use the destination alignment here?

dneilson abandoned this revision.Feb 9 2018, 1:49 PM