[llvm] [AArch64] Generate zeroing forms of certain SVE2.2 instructions (1/n) (PR #115535)

Paul Walker via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 14 06:37:29 PST 2024


================
@@ -4442,3 +4442,45 @@ let Predicates = [HasSVE, HasCPA] in {
   // Multiply-add vectors, writing addend
   def MLA_CPA : sve_int_mla_cpa<"mlapt">;
 }
+
+multiclass sve_int_un_pred_arit_bitwise_fp_pat<SDPatternOperator op> {
+  let Predicates = [HasSVEorSME, NotHasSVE2p2orSME2p2] in {
+    defm : SVE_1_Op_PassthruUndef_Pat<nxv8f16, op, nxv8i1, nxv8f16, !cast<Pseudo>(NAME # _ZPmZ_H_UNDEF)>;
+    defm : SVE_1_Op_PassthruUndef_Pat<nxv4f16, op, nxv4i1, nxv4f16, !cast<Pseudo>(NAME # _ZPmZ_H_UNDEF)>;
+    defm : SVE_1_Op_PassthruUndef_Pat<nxv2f16, op, nxv2i1, nxv2f16, !cast<Pseudo>(NAME # _ZPmZ_H_UNDEF)>;
+    defm : SVE_1_Op_PassthruUndef_Pat<nxv4f32, op, nxv4i1, nxv4f32, !cast<Pseudo>(NAME # _ZPmZ_S_UNDEF)>;
+    defm : SVE_1_Op_PassthruUndef_Pat<nxv2f32, op, nxv2i1, nxv2f32, !cast<Pseudo>(NAME # _ZPmZ_S_UNDEF)>;
+    defm : SVE_1_Op_PassthruUndef_Pat<nxv2f64, op, nxv2i1, nxv2f64, !cast<Pseudo>(NAME # _ZPmZ_D_UNDEF)>;
+  }
+
+  let Predicates = [HasSVE2p2orSME2p2] in {
+    def : SVE_1_Op_PassthruUndefZero_Pat<nxv8f16, op, nxv8i1, nxv8f16, !cast<Instruction>(NAME # _ZPzZ_H)>;
+    def : SVE_1_Op_PassthruUndefZero_Pat<nxv4f16, op, nxv4i1, nxv4f16, !cast<Instruction>(NAME # _ZPzZ_H)>;
+    def : SVE_1_Op_PassthruUndefZero_Pat<nxv2f16, op, nxv2i1, nxv2f16, !cast<Instruction>(NAME # _ZPzZ_H)>;
+    def : SVE_1_Op_PassthruUndefZero_Pat<nxv4f32, op, nxv4i1, nxv4f32, !cast<Instruction>(NAME # _ZPzZ_S)>;
+    def : SVE_1_Op_PassthruUndefZero_Pat<nxv2f32, op, nxv2i1, nxv2f32, !cast<Instruction>(NAME # _ZPzZ_S)>;
+    def : SVE_1_Op_PassthruUndefZero_Pat<nxv2f64, op, nxv2i1, nxv2f64, !cast<Instruction>(NAME # _ZPzZ_D)>;
+  }
+}
+
+defm FABS : sve_int_un_pred_arit_bitwise_fp_pat<AArch64fabs_mt>;
+defm FNEG : sve_int_un_pred_arit_bitwise_fp_pat<AArch64fneg_mt>;
----------------
paulwalker-arm wrote:

Sorry for being unclear.  I'm not asking for anything exotic, only a shuffling of the table gen to achieve the preferred schema of:
```
defm INST : class_to_define_instr<opcode, ...  dag_node>
```
For the zeroing instructions I expect to see the instruction definition classes contain the patterns necessary to match them. When these zeroing instructions are available we have no need for the _UNDEF pseudo instructions and so I'm suggesting you break them out into their own class.  My reference to `FADD` is only meant in relation to the layout of the instruction definitions where we have the `FADD_ZPmZ` definition, following by a definition of `FADD_ZPZZ` for the undef pseudos and I'm proposing you do likewise for the unary instructions albeit guarded with your new predicate. More specifically:

```
  defm ABS_ZPmZ  : sve_int_un_pred_arit<  0b110, "abs",  ABS_ZPZ, AArch64abs_mt>;
  defm NEG_ZPmZ  : sve_int_un_pred_arit<  0b111, "neg",  NEG_ZPZ, AArch64neg_mt>;

let Predicates = [HasSVEorSME, HasYouNewFeatureFlag] in {
  defm ABS_ZPZ : sve_int_unary_pred_bhfd<AArch64abs_mt>;
  defm NEG_ZPZ : sve_int_unary_pred_bhfd<AArch64neg_mt>;
}

.....
let Predicates = [HasSVE2p2orSME2p2] in {
  defm ABS_ZPzZ   : sve_int_un_pred_arit_z<  0b110, "abs", AArch64abs_mt>;
  defm NEG_ZPzZ   : sve_int_un_pred_arit_z<  0b111, "neg", AArch64neg_mt>;
}
```

You can minimise the change further by using `defm ABS_ZPmZ : sve_int_unary_pred_bhfd...` because then sve_int_un_pred_arit's interface  doesn't need to change.  My version is more consistent but I'll take the shorter form if that's your preference.

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


More information about the llvm-commits mailing list