[llvm] [RISCV] Stash GPR to FPR if emergency spill slot is not reachable (PR #180685)
Craig Topper via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 9 22:59:19 PST 2026
topperc wrote:
> > This seems like a hack. It doesn't work when the D extension isn't present.
> > I think the patch below is the beginning of a better fix, but it causes other issues that need to be worked through. Ignore the mention of ARM. This was copy and pasted as an experiment to fix #180199.
> > ```
> > @@ -1860,7 +1864,16 @@ void RISCVFrameLowering::processFunctionBeforeFrameFinalized(
> > // by the frame pointer.
> > // Let eliminateCallFramePseudoInstr preserve stack space for it.
> > bool RISCVFrameLowering::hasReservedCallFrame(const MachineFunction &MF) const {
> > - return !MF.getFrameInfo().hasVarSizedObjects() &&
> > + const MachineFrameInfo &MFI = MF.getFrameInfo();
> > + unsigned CFSize = MFI.getMaxCallFrameSize();
> > + // It's not always a good idea to include the call frame as part of the
> > + // stack frame. ARM (especially Thumb) has small immediate offset to
> > + // address the stack frame. So a large call frame can cause poor codegen
> > + // and may even makes it impossible to scavenge a register.
> > + if (CFSize >= ((1 << 12) - 1) / 2) // Half of imm12
> > + return false;
> > +
> > + return !MFI.hasVarSizedObjects() &&
> > !(hasFP(MF) && hasRVVFrameObject(MF));
> > }
> > ```
>
> Yes you are right. It has some issue such as requires D extension and the issue still exists if FPR is also used up. While I guess it's okay since it can be a workaround for rv64gc for now and be replaced by a more elegant solution later. PowerPC does the similar thing so I think it's not quite tricky.
What is the urgency to do this instead of a proper fix?
https://github.com/llvm/llvm-project/pull/180685
More information about the llvm-commits
mailing list