[PATCH] D127870: [RISCV] Fold prepass back into InsertVSETVLI data flow [nfc-ish]

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: craig.topper, kito-cheng, frasercrmck.
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, shiva0217, 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.

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.

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, but the test changes are pretty minimal.  The one change here is the result of the prepass not using needVSETVLI.  It could easily have been extended with that, so the sole difference is pretty unconvincing.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127870

Files:
  llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-unaligned.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D127870.437200.patch
Type: text/x-patch
Size: 10084 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220615/c662ae5b/attachment.bin>