[llvm] [RISCV][GISel] Reverse the operands the buildStore created in legalizeVAStart. (PR #73989)

[Craig Topper via llvm-commits]

================
@@ -0,0 +1,41 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=riscv32 -run-pass=legalizer %s -o - | FileCheck --check-prefix=RV32 %s
+
+--- |
+  declare void @llvm.va_start(ptr) #0
+
+  define void @test_va_start(ptr %0, ptr %1, ptr %2, ptr %3, ptr %4, ptr %5, ptr %6, ptr %7, ...) {
+    %va = alloca ptr
+    call void @llvm.va_start(ptr %va)
+    ret void
+  }
+
+  attributes #0 = { nocallback nofree nosync nounwind willreturn }
+
+...
+---
+name:            test_va_start
+tracksRegLiveness: true
+fixedStack:
+  - { id: 0, size: 4, alignment: 16, isImmutable: true }
----------------
topperc wrote:

The ABI alignment for any legal type on RISC-V is the size of the type. So pointers are aligned to XLEN/8. i8 is aligned to 1 byte, i16 is aligned to 2 bytes, i32 is aligned to 4 bytes, etc.

The are some types in the psABI that are defined to have 16 byte alignment like `long double` and `__int128`. https://github.com/riscv-non-isa/riscv-elf-psabi-doc

The stack pointer alignment is a contract between all functions so that the code generation for any function can assume the stack pointer is 16 byte alignment. Otherwise we would need to emit code to align the stack pointer before we could put a `long double` or `__int128` on the stack. When we generate code for a function, we know the stack started off 16 byte aligned. When we allocate things on the stack, we make sure that we always pad if needed to keep the stack pointer 16 byte aligned. This ensures the stack pointer is 16 byte aligned for any function calls.

https://github.com/llvm/llvm-project/pull/73989