[all-commits] [llvm/llvm-project] d4ce06: [RISCV][PrologEpilogInserter] "Float" emergency sp...

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

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d4ce062340064c3f73b8f6136c7350a5abe83cac
      https://github.com/llvm/llvm-project/commit/d4ce062340064c3f73b8f6136c7350a5abe83cac
  Author: Roger Ferrer Ibanez <roger.ferrer at bsc.es>
  Date:   2021-01-23 (Sat, 23 Jan 2021)

  Changed paths:
    M llvm/lib/CodeGen/PrologEpilogInserter.cpp
    M llvm/test/CodeGen/AArch64/framelayout-scavengingslot.mir
    M llvm/test/CodeGen/AArch64/framelayout-sve-scavengingslot.mir
    M llvm/test/CodeGen/AArch64/swiftself-scavenger.ll
    M llvm/test/CodeGen/AMDGPU/pei-scavenge-vgpr-spill.mir
    A llvm/test/CodeGen/RISCV/out-of-reach-emergency-slot.mir
    M llvm/test/CodeGen/Thumb/emergency-spill-slot.ll

  Log Message:
  -----------
  [RISCV][PrologEpilogInserter] "Float" emergency spill slots to avoid making them immediately unreachable from the stack pointer

In RISC-V there is a single addressing mode of the form imm(reg) where
imm is a signed integer of 12-bit with a range of [-2048..2047] bytes
from reg.

The test MultiSource/UnitTests/C++11/frame_layout of the LLVM test-suite
exercises several scenarios with the stack, including function calls
where the stack will need to be realigned to to a local variable having
a large alignment of 4096 bytes.

In situations of large stacks, the RISC-V backend (in
RISCVFrameLowering) reserves an extra emergency spill slot which can be
used (if no free register is found) by the register scavenger after the
frame indexes have been eliminated. PrologEpilogInserter already takes
care of keeping the emergency spill slots as close as possible to the
stack pointer or frame pointer (depending on what the function will
use). However there is a final alignment step to honour the maximum
alignment of the stack that, when using the stack pointer to access the
emergency spill slots, has the side effect of setting them farther from
the stack pointer.

In the case of the frame_layout testcase, the net result is that we do
have an emergency spill slot but it is so far from the stack pointer
(more than 2048 bytes due to the extra alignment of a variable to 4096
bytes) that it becomes unreachable via any immediate offset.

During elimination of the frame index, many (regular) offsets of the
stack may be immediately unreachable already. Their address needs to be
computed using a register. A virtual register is created and later
RegisterScavenger should be able to find an unused (physical) register.
However if no register is available, RegisterScavenger will pick a
physical register and spill it onto an emergency stack slot, while we
compute the offset (restoring the chosen register after all this). This
assumes that the emergency stack slot is easily reachable (this is,
without requiring another register!).

This is the assumption we seem to break when we perform the extra
alignment in PrologEpilogInserter.

We can "float" the emergency spill slots by increasing (in absolute
value) their offsets from the incoming stack pointer. This way the
emergency spill slots will remain close to the stack pointer (once the
function has allocated storage for the stack, including the needed
realignment). The new size computed in PrologEpilogInserter is padding
so it should be OK to move the emergency spill slots there. Also because
we're increasing the alignment, the new location should stay aligned for
the purpose of the emergency spill slots.

Note that this change also impacts other backends as shown by the tests.
Changes are minor adjustments to the emergency stack slot offset.

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