[all-commits] [llvm/llvm-project] 0de2b2: [RISCV] Register fixed stack slots for callee save...

[Craig Topper via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0de2b26942f890a6ec84cd75ac7abe3f6f2b2e37
      https://github.com/llvm/llvm-project/commit/0de2b26942f890a6ec84cd75ac7abe3f6f2b2e37
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2024-02-13 (Tue, 13 Feb 2024)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
    M llvm/lib/Target/RISCV/RISCVFrameLowering.h
    M llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp
    M llvm/lib/Target/RISCV/RISCVRegisterInfo.h
    M llvm/test/CodeGen/RISCV/calling-conv-ilp32e.ll

  Log Message:
  -----------
  [RISCV] Register fixed stack slots for callee saved registers for -msave-restore/Zcmp (#81392)

PEI previously used fake frame indices for these callee saved registers.
These fake frame indices are not register with MachineFrameInfo. This
required them to be deleted form CalleeSavedInfo after PEI to avoid
breaking later passes. See #79535

Unfortunately, removing the registers from CalleeSavedInfo pessimizes
Interprocedural Register Allocation. The RegUsageInfoCollector pass runs
after PEI and uses CalleeSavedInfo.

This patch replaces #79535 by properly creating fixed stack objects
through MachineFrameInfo. This changes the stack size and offsets
returned by MachineFrameInfo which requires changes to how
RISCVFrameLowering uses that information.

In addition to the individual object for each register, I've also create
a single large fixed object that covers the entire stack area covered by
cm.push or the libcalls. cm.push must always push a multiple of 16 bytes
and the save restore libcall pushes a multiple of stack align. I think
this leaves holes in the stack where we could spill other registers, but
it matches what we did previously. Maybe we can optimize this in the
future.

The only test changes are due to stack alignment handling after the
callee save registers. Since we now have the fixed objects, on the stack
the offset is non-zero when an aligned object is processed so the offset
gets rounded up, increasing the stack size.

I suspect we might need some more updates for RVV related code. There is
very little or maybe even no testing of RVV mixed with Zcmp and
save-restore.