[llvm] [AArch64][SVE] Don't require 16-byte aligned SVE loads/stores with +strict-align (PR #119732)
Benjamin Maxwell via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 13 05:03:27 PST 2024
================
@@ -2569,6 +2569,17 @@ MVT AArch64TargetLowering::getScalarShiftAmountTy(const DataLayout &DL,
bool AArch64TargetLowering::allowsMisalignedMemoryAccesses(
EVT VT, unsigned AddrSpace, Align Alignment, MachineMemOperand::Flags Flags,
unsigned *Fast) const {
+
+ // Allow SVE loads/stores where the alignment >= the size of the element type,
+ // even with +strict-align. The SVE loads/stores do not require memory to be
+ // aligned more than the element type even without unaligned accesses.
+ // Without this, already aligned loads and stores are forced to have 16-byte
+ // alignment, which is unnecessary and fails to build as
+ // TLI.expandUnalignedLoad() and TLI.expandUnalignedStore() don't yet support
+ // scalable vectors.
+ if (VT.isScalableVector() && Alignment >= Align(VT.getScalarSizeInBits() / 8))
----------------
MacDue wrote:
I don't think it's a bug. Looking at `AArch64.UnalignedAccessFaults()` (used as part of the FP loads): https://developer.arm.com/documentation/ddi0602/2023-09/Shared-Pseudocode/aarch64-functions-memory?lang=en#AArch64.UnalignedAccessFaults.3 it looks like unaligned accesses are supported (depending on the configuration).
Also the langref states:
> The optional constant align argument specifies the alignment of the operation (that is, the alignment of the memory address). It is the responsibility of the code emitter to ensure that the alignment information is correct.
https://github.com/llvm/llvm-project/pull/119732
More information about the llvm-commits
mailing list