[PATCH] D100487: [AArch64][SVE] Lower MULHU/MULHS nodes to umulh/smulh instructions
Paul Walker via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 15 07:58:22 PDT 2021
paulwalker-arm added inline comments.
================
Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.h:92-93
MUL_PRED,
+ SMULH_PRED,
+ UMULH_PRED,
SDIV_PRED,
----------------
As the general rule we use the common node name suffixed with `_PRED`, so in this case these should be `MULHS_PRED` and `MULHU_PRED`.
================
Comment at: llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td:192
def AArch64mul_p : SDNode<"AArch64ISD::MUL_PRED", SDT_AArch64Arith>;
+def AArch64smulh_p : SDNode<"AArch64ISD::SMULH_PRED", SDT_AArch64Arith>;
+def AArch64umulh_p : SDNode<"AArch64ISD::UMULH_PRED", SDT_AArch64Arith>;
----------------
Just a note, because of my other comment, to say that this is fine, here we typically prefer the AArch64 names as you've used here, although it'll be nicer still if you maintained the existing alphabetical ordering :)
================
Comment at: llvm/test/CodeGen/AArch64/sve-fixed-length-int-mulh.ll:5
+; RUN: llc -aarch64-sve-vector-bits-min=1024 < %s | FileCheck %s -D#VBYTES=128 -check-prefixes=CHECK,VBITS_EQ_1024
+; RUN: llc -aarch64-sve-vector-bits-min=2048 < %s | FileCheck %s -D#VBYTES=256 -check-prefixes=CHECK,VBITS_EQ_1024
+
----------------
Should this be `VBITS_EQ_2048`?
================
Comment at: llvm/test/CodeGen/AArch64/sve-fixed-length-int-mulh.ll:67
+; CHECK-LABEL: smulh_v32i8:
+; VBITS_EQ_256: ptrue [[PG:p[0-9]+]].b, vl[[#min(VBYTES,32)]]
+; VBITS_EQ_256-DAG: ld1b { [[OP1:z[0-9]+]].b }, [[PG]]/z, [x0]
----------------
Given you're using `EQ_256` I doubt the `#min` logic means anything. That said, why not VBITS_GE_256, shouldn't the code be the same for larger vectors?
================
Comment at: llvm/test/CodeGen/AArch64/sve-fixed-length-int-mulh.ll:393
+; Don't use SVE for 64-bit vectors.
+define <1 x i64> @smulh_v1i64(<1 x i64> %op1, <1 x i64> %op2) #0 {
+; CHECK-LABEL: smulh_v1i64:
----------------
As there's no NEON instruction for i64 based vectors I'm wondering if it's worth using SVE for this case as well? much like we do for ISD::MUL.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D100487/new/
https://reviews.llvm.org/D100487
More information about the llvm-commits
mailing list