[PATCH] D131875: [AArch64][SVE] Add hadd and rhadd support

Paul Walker via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 8 04:32:36 PST 2022


paulwalker-arm added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:5146-5160
+  case Intrinsic::aarch64_sve_srhadd:
+  case Intrinsic::aarch64_sve_urhadd:
+  case Intrinsic::aarch64_sve_shadd:
+  case Intrinsic::aarch64_sve_uhadd: {
+    bool IsSignedAdd = (IntNo == Intrinsic::aarch64_sve_srhadd ||
+                        IntNo == Intrinsic::aarch64_sve_shadd);
+    bool IsRoundingAdd = (IntNo == Intrinsic::aarch64_sve_srhadd ||
----------------
We use the `_PRED` suffix for nodes where the result of inactive lanes does not matter.  This means this transform is not strictly safe (as in somebody might do something erroneous based on the name).

We have `convertMergedOpToPredOp` to convert from predicated intrinsics to `_PRED` nodes when it is safe to do so. The alternative is to change the ISD name but that seems wrong because for the IR side of things you really do want `_PRED` nodes to free up isel/register allocation by selecting.


================
Comment at: llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td:3295
   // SVE2 integer halving add/subtract (predicated)
-  defm SHADD_ZPmZ  : sve2_int_arith_pred<0b100000, "shadd",  int_aarch64_sve_shadd>;
-  defm UHADD_ZPmZ  : sve2_int_arith_pred<0b100010, "uhadd",  int_aarch64_sve_uhadd>;
+  defm SHADD_ZPmZ  : sve2_int_arith_pred<0b100000, "shadd",  AArch64shadd_p>;
+  defm UHADD_ZPmZ  : sve2_int_arith_pred<0b100010, "uhadd",  AArch64uhadd_p>;
----------------
This ties in with my previous comment because typically here we'd create `SHADD_ZPZZ_UNDEF_B` pseudo instructions to free up the register allocator.  You don't need to bother with this for this patch if you don't want to but otherwise you'll need to handle `AArch64shadd_p` and `int_aarch64_sve_shadd` as separate patterns because they have different behaviour.

For an example of how we normally handle this see `MUL_ZPmZ` verses `MUL_ZPZZ`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131875/new/

https://reviews.llvm.org/D131875



More information about the llvm-commits mailing list