[PATCH] D139877: [RISCV]{InsertVSETVLI] Reverse traversal order of block in post pass [nfc]

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D139877#3989836 <https://reviews.llvm.org/D139877#3989836>, @craig.topper wrote:

> The phrase "block traversal" made me think you were changing the order we were visiting blocks. Which of course makes no sense for the local pass. Maybe "instruction traversal" would be better?

Does the reworded title clarify?



================
Comment at: llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp:1244
       if (!Used.VL && !Used.usedVTYPE()) {
-        ToDelete.push_back(PrevMI);
-        // fallthrough
-      } else if (canMutatePriorConfig(*PrevMI, MI, Used)) {
-        PrevMI->getOperand(2).setImm(MI.getOperand(2).getImm());
         ToDelete.push_back(&MI);
+        // Leave NextMI unchanged
----------------
craig.topper wrote:
> Why is NextMI relevant to whether this instruction can be removed?
This is one of the generalizations planned.

The basic idea here is we need to merge the demanded fields with the differences between the two vsetvlis to figure out if we can validly rewrite the former.  i.e. if tail policy is demanded, but the two differ, we can't rewrite the former, and thus can't remove the later.  

The case that's a bit tricky is when the following vsetvli either a) reads VL (via the preserving form), or b) reads a GPR which is defined between the two instructions.  The former should be handled by the implicit read when we visit NextMI being modeled in the Used set.  The later requires some care, and the current code uses this routine to be conservative around that case.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139877