[PATCH] D125232: [riscv] Fix data flow for VSETVLI insertion

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: frasercrmck, craig.topper.
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 second 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, the root issue comes down to the fact that the compatibility checks allow a block to be transparent (meaning not change the state flowing through) conditionally on the valid of the input state.

Consider a block which contains a single operation which demands VL, but not VTYPE. This block produces a new state if the incoming state is unknown, but produces a unchanged state if the incoming state is "compatible" with the incoming state.  They key point is that these outgoing states differ.  As such, the attempted caching in the current code produced incorrect results.

In the process of fixing that, I switched from the "leave it invalid until visited" to a "start unknown, then improve" framing.  I believe this is effectively switching from optimistic data flow to conservative data flow, but a) I find the later much easier to follow, and b) I don't believe it matters in this case.  The only case I can think of would be code with unreachable edges, but producing less optimal code when we haven't deleted trivially unreachable blocks doesn't seem particularly problematic.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125232

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D125232.428077.patch
Type: text/x-patch
Size: 16132 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220509/5d5ef1f3/attachment.bin>