[PATCH] D153070: [RISCV] Fix a latent miscompile in doPeepholeMaskedRVV

[Philip Reames via Phabricator via llvm-commits]

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

The code was using the tail policy being "agnostic" to select a instruction whose semantics were "undefined".  This was almost always fine (as the pass through operand was usually implicit_def), but could in theory lead to a miscompile.  I don't actually have a test case as it requires a later transform to exploit the wrong tail policy state, and I couldn't easily figure out to get vsetvli insertion to miscompile given the wrong state.  This was spotted by inspection, and it may be a miscompile in theory only at the moment.

Note that this may cause regressions if there are instructions for which we either don't have a _TU pseudo form, or the _TU pseudo form is missing a policy operand.  When I was first looking at this, I saw exactly that, and D153067 <https://reviews.llvm.org/D153067> exists to add the missing policy operand I noticed.

As a later follow up, I want to always force the use of _TU, but it seemed good to fix the bug, then driven the _TU transition in a separate patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153070

Files:
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp


Index: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
===================================================================
--- llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
+++ llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
@@ -3164,6 +3164,11 @@
          IsVMSet(MaskSetter.getMachineOpcode());
 }
 
+static bool isImplicitDef(SDValue V) {
+  return V.isMachineOpcode() &&
+         V.getMachineOpcode() == TargetOpcode::IMPLICIT_DEF;
+}
+
 // Optimize masked RVV pseudo instructions with a known all-ones mask to their
 // corresponding "unmasked" pseudo versions. The mask we're interested in will
 // take the form of a V0 physical register operand, with a glued
@@ -3190,8 +3195,7 @@
     if (I->UnmaskedTUPseudo == I->UnmaskedPseudo) {
       UseTUPseudo = true;
     } else {
-      if (!(N->getConstantOperandVal(*TailPolicyOpIdx) &
-            RISCVII::TAIL_AGNOSTIC)) {
+      if (!isImplicitDef(N->getOperand(0))) {
         // Keep the true-masked instruction when there is no unmasked TU
         // instruction
         if (I->UnmaskedTUPseudo == I->MaskedPseudo)
@@ -3236,11 +3240,6 @@
   return true;
 }
 
-static bool isImplicitDef(SDValue V) {
-  return V.isMachineOpcode() &&
-         V.getMachineOpcode() == TargetOpcode::IMPLICIT_DEF;
-}
-
 // Try to fold away VMERGE_VVM instructions. We handle these cases:
 // -Masked TU VMERGE_VVM combined with an unmasked TA instruction instruction
 //  folds to a masked TU instruction. VMERGE_VVM must have have merge operand


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D153070.531890.patch
Type: text/x-patch
Size: 1482 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230615/14043d20/attachment.bin>