[PATCH] D125382: [RISCV] Add a test w/ RVV stack objects misaligning non-RVV ones

[Fraser Cormack via Phabricator via llvm-commits]

frasercrmck created this revision.
frasercrmck added reviewers: rogfer01, craig.topper, HsiangKai, kito-cheng, StephenFan.
Herald added subscribers: sunshaoce, VincentWu, luke957, vkmr, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, edward-jones, zzheng, jrtc27, shiva0217, niosHD, sabuasal, simoncook, johnrusso, rbar, asb, arichardson.
Herald added a project: All.
frasercrmck requested review of this revision.
Herald added subscribers: llvm-commits, pcwang-thead, eopXD, MaskRay.
Herald added a project: LLVM.

This patch adds a simple test which demonstrates a miscompilation of
16-byte-aligned scalar (non-RVV) objects when combined with RVV stack
objects.

The RISCV stack is assumed to be aligned to 16 bytes, and this is
guaranteed/assumed to be true when setting up the stack. However, when
the stack contains RVV objects, we decrement the stack pointer by some
multiple of vlenb, which is only guaranteed to be aligned to 8 bytes.
This means that non-RVV objects specifically requiring 16-byte alignment
fall through the cracks and are misaligned. Objects requiring larger
alignment trigger stack realignment and thus should be okay.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125382

Files:
  llvm/test/CodeGen/RISCV/rvv/scalar-stack-align.ll


Index: llvm/test/CodeGen/RISCV/rvv/scalar-stack-align.ll
===================================================================
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rvv/scalar-stack-align.ll
@@ -0,0 +1,48 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+v -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s --check-prefix=RV32
+; RUN: llc -mtriple=riscv64 -mattr=+v -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s --check-prefix=RV64
+
+; FIXME: The stack is assumed to be aligned to 16 bytes but we only ensure an
+; 8-byte alignment for the section containing RVV objects. This means that
+; 16-byte scalar objects below the RVV objects which don't trigger realignment
+; are misaligned.
+
+define i64* @scalar_stack_align16() nounwind {
+; RV32-LABEL: scalar_stack_align16:
+; RV32:       # %bb.0:
+; RV32-NEXT:    addi sp, sp, -32
+; RV32-NEXT:    sw ra, 28(sp) # 4-byte Folded Spill
+; RV32-NEXT:    csrr a0, vlenb
+; RV32-NEXT:    sub sp, sp, a0
+; RV32-NEXT:    addi a0, sp, 16
+; RV32-NEXT:    call extern at plt
+; RV32-NEXT:    mv a0, sp
+; RV32-NEXT:    csrr a1, vlenb
+; RV32-NEXT:    add sp, sp, a1
+; RV32-NEXT:    lw ra, 28(sp) # 4-byte Folded Reload
+; RV32-NEXT:    addi sp, sp, 32
+; RV32-NEXT:    ret
+;
+; RV64-LABEL: scalar_stack_align16:
+; RV64:       # %bb.0:
+; RV64-NEXT:    addi sp, sp, -16
+; RV64-NEXT:    sd ra, 8(sp) # 8-byte Folded Spill
+; RV64-NEXT:    csrr a0, vlenb
+; RV64-NEXT:    sub sp, sp, a0
+; RV64-NEXT:    addi a0, sp, 8
+; RV64-NEXT:    call extern at plt
+; RV64-NEXT:    mv a0, sp
+; RV64-NEXT:    csrr a1, vlenb
+; RV64-NEXT:    add sp, sp, a1
+; RV64-NEXT:    ld ra, 8(sp) # 8-byte Folded Reload
+; RV64-NEXT:    addi sp, sp, 16
+; RV64-NEXT:    ret
+  %a = alloca <vscale x 2 x i32>
+  %c = alloca i64, align 16
+  call void @extern(<vscale x 2 x i32>* %a)
+  ret i64* %c
+}
+
+declare void @extern(<vscale x 2 x i32>*)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D125382.428641.patch
Type: text/x-patch
Size: 1946 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220511/898c52e6/attachment.bin>