[PATCH] D125133: [riscv] Fix state tracking bug on vsetvli (phi of vsetvli) peephole

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 6 14:30:55 PDT 2022


reames created this revision.
reames added reviewers: craig.topper, frasercrmck, khchen, jacquesguan, fakepaper56.
Herald added subscribers: sunshaoce, VincentWu, luke957, StephenFan, vkmr, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, kito-cheng, niosHD, sabuasal, bollu, simoncook, johnrusso, rbar, asb, hiraditya, arichardson, mcrosier.
Herald added a project: All.
reames requested review of this revision.
Herald added subscribers: pcwang-thead, eopXD, MaskRay.
Herald added a project: LLVM.

This fixes the first of several cases where the state computed in phase 1 and 2 of the algorithm differs from the state computed during phase 3.  Note that such differences can cause miscompiles by creating disagreements about contents of the VL and VTYPE registers at block boundaries.

In this particular case, we recognize that for the first vsetvli in a block, that if the AVL is a phi of GPR results from previous vsetvlis and the VTYPE field matches, we can avoid emitting a vsetvli as the register contents don't change.  Unfortunately, the abstract state does change and that update was lost.

As noted in the test change, this can actually improve results by preserving information until later state transitions in the block.  However, this minor codegen improvement is not the motivation for the patch.  The motivation is to avoid cases a case where we break a key internal correctness invariant.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125133

Files:
  llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll


Index: llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
===================================================================
--- llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
+++ llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
@@ -453,7 +453,7 @@
 ; CHECK-NEXT:    vle32.v v16, (a2)
 ; CHECK-NEXT:    slli a4, a3, 2
 ; CHECK-NEXT:    add a1, a1, a4
-; CHECK-NEXT:    vsetvli zero, a3, e32, m8, tu, mu
+; CHECK-NEXT:    vsetvli zero, zero, e32, m8, tu, mu
 ; CHECK-NEXT:    vfmacc.vf v16, fa0, v8
 ; CHECK-NEXT:    vse32.v v16, (a2)
 ; CHECK-NEXT:    sub a0, a0, a3
Index: llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
===================================================================
--- llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
+++ llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
@@ -1124,8 +1124,20 @@
         // use the predecessor information.
         assert(BlockInfo[MBB.getNumber()].Pred.isValid() &&
                "Expected a valid predecessor state.");
-        if (needVSETVLI(NewInfo, BlockInfo[MBB.getNumber()].Pred) &&
-            needVSETVLIPHI(NewInfo, MBB)) {
+        if (needVSETVLI(NewInfo, BlockInfo[MBB.getNumber()].Pred)) {
+          // IF this is the first implicit state change, and the state change
+          // requested can be proven to produce the same register contents, we
+          // can skip emitting the actual state change and continue as if we
+          // had since we know the GPR result of the implicit state change
+          // wouldn't be used and VL/VTYPE registers are correct.  Note that
+          // we *do* need to model the state as if it changed as while the
+          // register contents are unchanged, the abstract model can change.
+          if (!needVSETVLIPHI(NewInfo, MBB)) {
+            CurInfo = NewInfo;
+            PrevVSETVLIMI = nullptr;
+            continue;
+          }
+
           insertVSETVLI(MBB, MI, NewInfo, BlockInfo[MBB.getNumber()].Pred);
           CurInfo = NewInfo;
         }


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D125133.427746.patch
Type: text/x-patch
Size: 1990 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220506/c447a1a1/attachment.bin>


More information about the llvm-commits mailing list