[all-commits] [llvm/llvm-project] ef76a3: [RISCV] Fix offset computation for RVV

[Roger Ferrer Ibáñez via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ef76a333faca3e41036f60bb598173d410aab24b
      https://github.com/llvm/llvm-project/commit/ef76a333faca3e41036f60bb598173d410aab24b
  Author: Roger Ferrer Ibanez <roger.ferrer at bsc.es>
  Date:   2021-03-29 (Mon, 29 Mar 2021)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
    M llvm/lib/Target/RISCV/RISCVFrameLowering.h
    M llvm/lib/Target/RISCV/RISCVMachineFunctionInfo.h
    M llvm/test/CodeGen/RISCV/rvv/localvar.ll
    M llvm/test/CodeGen/RISCV/rvv/rv32-spill-vector-csr.ll
    M llvm/test/CodeGen/RISCV/rvv/rv64-spill-vector-csr.ll
    M llvm/test/CodeGen/RISCV/rvv/rvv-framelayout.ll
    M llvm/test/CodeGen/RISCV/rvv/wrong-stack-slot-rv32.mir
    M llvm/test/CodeGen/RISCV/rvv/wrong-stack-slot-rv64.mir

  Log Message:
  -----------
  [RISCV] Fix offset computation for RVV

In D97111 we changed the RVV frame layout when using sp or bp to address
the stack slots so we could address the emergency stack slot. The idea
is to put the RVV objects as far as possible (in offset terms) from the
frame reference register (sp / fp / bp).

When using fp this happens naturally because the RVV objects are already
the top of the stack and due to the constraints of RVV (VLENB being a
power of two >= 128) the stack remains aligned. The rest of this summary
does not apply to this case.

When using sp / bp we need to skip the non-RVV stack slots. The size of
the the non-RVV objects is computed subtracting the callee saved
register size (whose computation is added in D97111 itself) to the total
size of the stack (which does not account for RVV stack slots). However,
when doing so we round to 16 bytes when computing that size and we end
emitting a smaller offset that may belong to a scalar stack slot (see
D98801). So this change removes that rounding.

Also, because we want the RVV objects be between the non-RVV stack slots
and the callee-saved register slots, we need to make sure the RVV
objects are properly aligned to 8 bytes. Adding a padding of 8 would
render the stack unaligned. So when allocating space for RVV (only when
we don't use fp) we need to have extra padding that preserves the stack
alignment. This way we can round to 8 bytes the offset that skips the
non-RVV objects and we do not misalign the whole stack in the way. In
some circumstances this means that the RVV objects may have padding
before (=lower offsets from sp/bp) and after (before the CSR stack
slots).

Differential Revision: https://reviews.llvm.org/D98802