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

Hsiangkai Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 5 21:56:09 PST 2020


HsiangKai added a comment.

In D89449#2361279 <https://reviews.llvm.org/D89449#2361279>, @frasercrmck wrote:

> Would you be able to explain how spills & reloads of vector registers work with this method? Namely, LLVM can insert spills and reloads at any point in the instruction sequence (IIRC). I would imagine that this includes right between VSETVLI/PseudoInst pairs:
>
>   dead %25:gpr = PseudoVSETVLI %12:gpr, /*e32,mf4*/, implicit-def $vl, implicit-def $vtype
>   ; insert spill of V4 here!
>   %17:vr = PseudoVFMUL_VF_M1 %18:vr(tied-def 0), killed %13:vr, %15:fpr64, $noreg, $noreg, -1, implicit $vl, implicit $vtype
>
> I would imagine that the spill needs its own `VSETVLI` as it must spill the whole physical register: it must ensure a `vtype` of e.g. `e8,m1`. If it needs to spill `V4M4` it would configure `e8,m4`.  This is likely overwrite the previous configuration, so will we have to save/restore `vtype` around the spill/reload? I'm not sure that's possible in general. I don't even think `storeRegToStackSlot` and `loadRegFromStackSlot` allow the insertion of multiple MIs, and we'd need a reserved/scavenged register. Though perhaps there's another trick I'm not thinking of.

There is no need to specify the vtype for spilling code. In RVV specification, we have whole register load/store without setting vtype. To know LMUL values is enough to do spilling.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D89449



More information about the llvm-commits mailing list