[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