[llvm] [DAG] Add legalization handling for ABDS/ABDU (PR #92576)
David Green via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 26 03:06:37 PDT 2024
================
@@ -24,9 +24,10 @@ define <vscale x 16 x i8> @saba_b(<vscale x 16 x i8> %a, <vscale x 16 x i8> %b,
define <vscale x 16 x i8> @saba_b_promoted_ops(<vscale x 16 x i8> %a, <vscale x 16 x i1> %b, <vscale x 16 x i1> %c) #0 {
; CHECK-LABEL: saba_b_promoted_ops:
; CHECK: // %bb.0:
-; CHECK-NEXT: mov z1.b, p0/z, #-1 // =0xffffffffffffffff
-; CHECK-NEXT: mov z2.b, p1/z, #-1 // =0xffffffffffffffff
-; CHECK-NEXT: saba z0.b, z1.b, z2.b
+; CHECK-NEXT: ptrue p2.b
+; CHECK-NEXT: mov z1.b, #1 // =0x1
+; CHECK-NEXT: eor p0.b, p2/z, p0.b, p1.b
+; CHECK-NEXT: add z0.b, p0/m, z0.b, z1.b
----------------
davemgreen wrote:
I'm not sure what it is aiming to test. I think it could end up as two predicated add's of 1. It seems OK to me for this one to change.
I'm not sure if I wrote this elsewhere but I have always found it odd for DAG combiner to generate nodes that the target will never use. I understand how it is useful for vectors, and can help with canonicalisation, but it feels that should be done earlier if needed and instruction selection should be moving towards what is legal, not away from it. That aside I do trust this will work OK given enough work.
We probably have very few tests for scalar abd's though, mostly vector. Is it worth adding some for various architectures?
https://github.com/llvm/llvm-project/pull/92576
More information about the llvm-commits
mailing list