[all-commits] [llvm/llvm-project] dc562d: [RISCV] Fold prepass back into InsertVSETVLI data ...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dc562d570dfe7589a27497c1210b105d9d8603f0
      https://github.com/llvm/llvm-project/commit/dc562d570dfe7589a27497c1210b105d9d8603f0
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-06-20 (Mon, 20 Jun 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp

  Log Message:
  -----------
  [RISCV] Fold prepass back into InsertVSETVLI data flow [nfc-ish]

When working through correctness issues in this pass, I moved a number of transforms which were phrased as mutating prior vsetvli instructions out of the main data flow because mutating prior instructions can invalidate the running dataflow results in subtle ways. We ended up creating both a prepass and a post-pass.

After consideration, I believe the prepass to be redundant, and this change removes it by folding it back into the data flow via a key conceptual change. Instead of phrasing the mutations on instructions, we can phrase them on abstract states. This avoids the dataflow inconsistency problem mentioned above by simply propagating the potential change forward, and thus reflecting its results in the dataflow.  Critically, we do so without modifying existing VSETVLI instructions; some of the data flow steps include non-local IR analysis.

Compile time wise, this removes a linear pass, but has the potential to increase the number of iterations for the data flow to converge. That's not a algorithmic complexity change, the needVSETVLI mechanism has the same effect. In practice, I don't see this triggering more iterations, so I think it's likely to be a net win overall. (I didn't do any careful analysis here; just an impression from glancing at a couple tests.)

This has the potential to produce better results, so this isn't strictly speaking NFC.

Differential Revision: https://reviews.llvm.org/D127870