[PATCH] D93804: [RISCV] Spilling for RISC-V V extension.

Sam Elliott via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 14 09:42:14 PST 2021


lenary added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:97
+  // enabled. See llvm/test/CodeGen/RISCV/rvv/spill-vector-csr.ll.
+  if (TFI->hasFP(MF) || Subtarget.hasStdExtV())
     markSuperRegs(Reserved, RISCV::X8); // fp
----------------
HsiangKai wrote:
> craig.topper wrote:
> > frasercrmck wrote:
> > > HsiangKai wrote:
> > > > frasercrmck wrote:
> > > > > Should `hasFP` not pessimistically return true if V is enabled?
> > > > Do you mean to move Subtarget.hasStdExtV() into hasFP()? To consider spilling, it seems reasonable.
> > > Yeah, that's what I meant. I believe I had a thought a few hours after that comment why you might not want `hasStdExtV` in `hasFP`, but I've forgotten it now.
> > I don't see an equivalent of this in AArch64 when SVE is enabled. How are the avoiding needing a frame pointer?
> Indeed, it is possible to access frame objects without reserving frame pointer when there is any RVV objects on the stack. If we do not leverage frame pointer when there is any RVV objects, all frame object accesses will need do some polynomial calculation.
> 
> Now, there is a new type to represent two dimensions stack offset. I could try to implement it without reserving the frame pointer.
Being deep within `hasFP` code right now, and seeing that it has some nasty edge-cases when introducing ilp32e, it seems prudent to start with a conservatively correct approach for the initial implementation, and then optimise to avoid using frame pointers if necessary? 

That should also make reviewer's lives easier :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93804/new/

https://reviews.llvm.org/D93804



More information about the llvm-commits mailing list