[LLVM][XTHeadVector] Expand pseudo VMV<n>R generated by the ExpandPostRAPseudos correctly.

[AinsleySnow]

A WIP PR. Now we can have the VMV<n>R pseudo nodes generated by the ExpandPostRAPseudos pass correctly expanded. Here's an overview about what we have done right now.

• Correct VRCs and LMULs (4e61244962740bd0b7bc0939ac63210d5a046605).
• Extract some code of the original emitXWholeMove to make the logic accessible across passes (8e8338f735e22954504f59dc6f95f78fffbe91b3), and then override expandPostRAPseudo in RISCVInstrInfo (0f5fe93e660f81bea2429dffe57b1b204c7db1bc), avoiding the pass generating VMV<n>R pseudos and then leaving them be.
• When the n in VMV<n>R is 1, treat it separately because we cannot get subregister from a plain VR (afaf040a0b6838a5217df1ae455fedfb5a3d9772).
• The tests are adapted from RVV 1.0's vmv-copy test.

I don't think it is unnecessary to adjust vtype and vl before we use the pseudo VMV<n>R, because I think the behavior of vmv.v.v can be affected by previously set vtype and vl.

We need more tests as well. Namely, we need tests written in LLVM IR, focusing on the vmv.v.v generated for vlseg (or vsseg) intrinsic.

Please let me know if you have any suggestion!

[imkiva]

Excellent refactoring, and thanks for the bug fix for NREGS = 1

[imkiva]

because I think the behavior of vmv.v.v can be affected by previously set vtype and vl.

I agree. The specification states "This instruction copies the vs1, rs1, or immediate operand to the first vl locations of the destination vector."

[AinsleySnow]

The new commits correctly adjust VL and VTYPE for pseudo VMV<n>R.

We achieved this by explicitly generate vsetvli instructions in the RISCVInsertVSETVLI pass. While it is nice to do all the things in the ExpandPostRAPseudos pass, we found it difficult to get temporary registers there. Finally we decided to adjust VL and VTYPE in the RISCVInsertVSETVLI pass as a temporary workaround.

Here's an overview of it.

• Walk through all the instructions in a basic block and find out which COPY instruction may finally turn into pseudo VMV<n>R.
• Save origin VL and VTYPE and set VL to VLMAX, LMUL to m1 and SEW to e8 in front of the COPY node (I'm quite not sure about this - theoretically any SEW would be okay. Maybe I need to read GCC's source code.). Then restore the value in the back of it. Since we always expand pseudo VMV<n>R to a line of vmv.v.v, we need to find the corresponding REG_SEQUENCE node (if there is) and restore after it. Otherwise the restpring vsetvli may appear in the middle of a line of vmv.v.vs.
• The scheduler may move the COPY node around (i.e. move the node to the front of the vsetvli). Therefore I override the isSchedulingBoundary method.
• The expand is correct but it will generate lots of unnecessary instructions. This is because in the InsertVSETVLI stage some redundancy COPY nodes get their VL and VTYPE adjusted as well. The COPY nodes themselves are eliminated in latter passes, but the instructions generated for them are not.

Please let me know if you have any suggestions!

[imkiva]

Excellent work! Will review in a day.

I am wondering if such redundant csrr+vsetvli will be removed when a higher optimization level is applied, like -O2 or -O3?

[AinsleySnow]

First of all thank you for the compliment~

I am wondering if such redundant csrr+vsetvli will be removed when a higher optimization level is applied, like -O2 or -O3?

No, the redundant csrr+vsetvli remain there. Maybe we should manually remove them when eliminating redundant copy nodes.

[imkiva]

No, the redundant csrr+vsetvli remain there. Maybe we should manually remove them when eliminating redundant copy nodes.

I skimmed RISCVRedundantCopyElimination and it looks similar to insertVSETVLIForCOPY but with additional conditions and steps (mainly the for-loop). Is it possible that we only insertVSETVLIForCOPY after that? ---- UPDATE: No, as redundant copy elimination happens after register allocation.

Or can we extract the checks in RISCVRedundantCopyElimination to RISCVInstrInfo, and check if the copy node will be removed afterward and not insert the csrr+vsetvli sequence if so?

[AinsleySnow]

Or can we extract the checks in RISCVRedundantCopyElimination to RISCVInstrInfo, and check if the copy node will be removed afterward and not insert the csrr+vsetvli sequence if so?

Sounds great. Thank you for your advice! I will look into it.

[imkiva]

Maybe we can extract the code generating backup-action-restore to a separate function, and reuse them in emitXWholeLoadStore and this pass.

[AinsleySnow]

The newly pushed three commits extract common code of emitXWholeLoadStore and insertVSETVLIForCOPY. Unfortunately we cannot use the logic in RISCVRedundantCopyElimination to eliminate the COPY nodes.

The redundant COPY nodes here are actually deleted in VirtRegRewriter. Some COPY nodes, which are recognized as "convertible to vmv.v.v", will get same source and destination after register allocation, and the pass remove these nodes. It is hard to detect these kind of COPY nodes before register allocation!

It is likely that we must address the "pseudo vmv problem" from its root...

[imkiva]

LGTM

[imkiva]

I think PseudoTH_VSETVLIX0 is theoretically better than TH_VSETVLI. Some internal passes work only with the pseudo version like isConvertibleToVMV. But that's up to you 😉 And sorry for the confusion in my code 😢

[AinsleySnow]

I suddenly realized that maybe it is inappropriate to use TH_VSETVLI here. I did the modification because the RISCVInsertVSETVLI pass will check whether a PseudoVSETVLI instruction is of the form vsetvli x0, x0, vtype and abort if it is. So if we use the Pseudo version some of our tests will crash.

But in RVV 0.7.1 the meaning of vsetvli x0, x0, vtype has subtle difference from that in RVV 1.0. I will check if we can get around the assertion and use the pseudo version for better performance here.

Thank you for pointing it out!

[AinsleySnow]

The two new commits use PseudoTH_VSETVLIX0 in the adjustVLVTYPE method.

vsetvli x0, x0, vtype has different meaning between RVV 1.0 and RVV 0.7.1. In RVV 1.0, the instruction operates as if the current vector length in vl is used as the AVL, and the resulting value is written to vl. In RVV 0.7.1, however, the behavior of the instruction is not affected by rd and the instruction just set VL to VLMAX, without saving new VL.

The RISCVInsertVSETVLI pass cannot handle pseudo vsetvli with rd and rs1 both set to x0. But in RVV 0.7.1 the instruction just operates as if it were vsetvli rd, x0, vtype in RVV 1.0. Therefore I disabled the "X0, X0 VSETVLI" assertion when using RVV 0.7.1.

The RISCVInsertVSETVLI pass treats all vsetvlis with x0 as their destination register as results not used. These vsetvlis may get deleted in the doLocalPostpass method. So I added checks about whether we're using RVV 0.7.1 to avoid doLocalPostpass incorrectly deleting necessary vsetvlis.

[imkiva]

Thanks for the fix. LGTM now.