[llvm] [RISCV] RISC-V split register allocation and move vsetvl pass in between (PR #70549)

[Piyou Chen via llvm-commits]

BeMg wrote:

> Oh, very interesting! Thanks for working on this. I didn't know we could do partial register allocation (RA)!
> 
> I have some high-level questions:
> 
> > 1. unblock scheduler's constraints by removing vl/vtype def-use chain
> 
> Just for me to understand, this would not require RA of RVV registers byt itself. We would still need to run the InsertVSETVL pass late, like you're doing now. Is that correct?

Yes. For scheduler, it actually doesn't need change the register allocator.

> 
> However splitting the passes unlocks the two following cases:
> 
> > 2. Support RVV re-materialization
> 
> I understand that here you will we able to do that because you have only RA'd RVV registers and the GPR virtual registers that we use as carriers of the VL value make this a bit easier. Is my intuition correct here?

I just consider the trival case in remat now. Remove Implict use `vl/vtype` not only unblock scheduler but also make default remat   (`isReallyTriviallyReMaterializable`) in RVV instruction possible. (For example, `vid` and `vmv`)

https://github.com/llvm/llvm-project/blob/e98f3bfff2c499e76ce8784ea15cedbfb83b33bf/llvm/lib/CodeGen/TargetInstrInfo.cpp#L1130

The more complicated case (include some def-use chain) could be the further work by define RISC-V own remat hook or make the new pseudo to make it suitable for default remat.

> > 3. Support partial spill
> 
> Similar as above, I imagine you plan to emit a `PseudoVSPILL_VL` / `PseudoVRELOAD_VL` instruction or something like that, right?

Yes. We plan to add the concrete size information for each MachineInstruction. With these information, we can update the RISCVInstrInfo::storeRegToStackSlot and RISCVInstrInfo::loadRegToStackSlot to make it emit the pseudo base on concrete size.

> Did you consider partial copies as well?

Not, but it work in same flow.

> 
> I * think * some of those might be hindered by the tail undisturbed policy which may still require to spill/copy the whole register. Do you think it does or it would already be handled after RA of RVV registers?

This is why we need the concrete size information to make sure the partial spill/reload doesn't break the correctness. 

> 
> Looking forward progress here, this looks promising!

Thanks for comment. 


https://github.com/llvm/llvm-project/pull/70549