[PATCH] D89449: [RISCV] Initial infrastructure for code generation of the RISC-V V-extension

PeiHsiangHung via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Dec 6 16:11:03 PST 2020


NickHung added a comment.

The matching pattern rules written in the tablegen file is a bit hard to maintain.
Would it be better if we can simplify this step?



================
Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:94
+  // V registers for code generation. We handle them manually.
+  markSuperRegs(Reserved, RISCV::VL);
+  markSuperRegs(Reserved, RISCV::VTYPE);
----------------
rogfer01 wrote:
> NickHung wrote:
> > The reserved VL and VTYPE would immediately dead after implicit def. How do you support the calling convention?  Both CSRs are caller-saved.
> To be honest we haven't outlined any calling convention at this stage yet. See for some ideas we're considering but nothing is set in stone https://github.com/riscv/rvv-intrinsic-doc/issues/38
> 
> However as you mention, even if both CSRs are caller-saved and given the current mechanism in which every instruction using them is prefixed with a `vsetvl`, `vl` is implicitly saved in a GPR whose value will be preserved through the call.
> 
> Until the calling convention is clarified, any pass that removes redundant `vsetvl` instructions must be aware that calls may have clobbered it.
> 
> From your question, though, now I realize that we want to extend the lowering of a call in selectiondag to assert in the regmask that `vl` and `vtype` are clobbered. I think this would the safe thing to do for the usual calling convention. Does this seem reasonable at this stage?
At this stage, inserting vsetvli in front of every instruction is 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89449



More information about the llvm-commits mailing list