[llvm] [RISCV][VLOPT] Add support for mask-register logical instructions and set mask instructions (PR #112231)

[Michael Maitland via llvm-commits]

================
@@ -475,6 +475,28 @@ static OperandInfo getOperandInfo(const MachineInstr &MI,
     return OperandInfo(EMUL, Log2EEW);
   }
 
+  // 15. Vector Mask Instructions
+  // 15.1. Vector Mask-Register Logical Instructions
+  // 15.4. vmsbf.m set-before-first mask bit
+  // 15.6. vmsof.m set-only-first mask bit
+  // EEW=1 and EMUL=(EEW/SEW)*LMUL
+  // We handle the cases when operand is a v0 mask operand above the switch,
+  // but these instructions may use non-v0 mask operands and need to be handled
+  // specifically.
+  case RISCV::VMAND_MM:
+  case RISCV::VMNAND_MM:
+  case RISCV::VMANDN_MM:
+  case RISCV::VMXOR_MM:
+  case RISCV::VMOR_MM:
+  case RISCV::VMNOR_MM:
+  case RISCV::VMORN_MM:
+  case RISCV::VMXNOR_MM:
+  case RISCV::VMSBF_M:
----------------
michaelmaitland wrote:

There are 4 cases to consider for each of these instructions:
1. There are no bits set
2. There is a bit set on [1, %vl)
3. The bit is set at %vl
4. There is a bit set on [%vl + 1, VLMAX]

For vmsbf.m, case 1 behaves the same regardless of the VL being optimized or not, since [1, %vl] will be set in both cases. Case 2 also behaves the same since we will set before the first mask bit but not the mask bit and all bits after it up to %vl will not get set. Case 3 will also act the same since all bits [1, %vl) will get set. Case 4 also performs the same -- imagine %vl + 1 is set, then [1, %vl] gets set. Since we never read %vl + 1, we don't care that it didn't get set. So it is safe to optimize this instruction.

For vmsif.m, case 1 behaves the same regardless of the VL being optimized for the same reason as above. Case 2 also behaves the same -- imagine %vl -1 is set, we can still set %vl -1 and all bits before it. Case 3 also acts the same since [1, %vl] will get set. Case 4 also acts the same -- imagine %vl + 1 is set, then [1, %vl] is set. We never read %vl + 1, so we don't care whether it got set or not. So it is safe to optimize this instruction.

For vmsof.m, case 1 behaves the same since no bits will be set on [1, %vl], just like the non-optimized version. Case 2 also behaves the same since we can set the active bit in [1, %vl) and all other bits on [1, %vl) will be zero. Case 3 also behaves the same since %vl gets set but no other bits on [1, %vl) will be active. Case 4 also behaves the same since all bits [1, %vl] will be inactive, and we never read %vl, so it doesn't matter if it is set or not. So it is safe to optimize this instruction.

Based on the consideration of all of these cases, I think it needs no special consideration. I believe there is no issue if we replace VLMAX with some other %vl2 which is larger than %vl.

https://github.com/llvm/llvm-project/pull/112231