-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[X86] combineVectorSizedSetCCEquality - allow 256/512-bit vector icmp_ne/eq zero comparisons #163373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…_ne/eq zero comparisons We avoid creating vector movmsk/ptest comparisons with zero if we can just use scalar OR instead, but this doesn't make sense for 256-bit or larger vectors which creates a more complex OR chain. This more closely matches what we do for icmp_ne/eq against non-zero values. I'm hoping that we can eventually allow even larger vectors to be handled with a OR/AND chains - but for now this just allows us to handle legal 256/512-bit vector widths.
|
@llvm/pr-subscribers-backend-x86 Author: Simon Pilgrim (RKSimon) ChangesWe avoid creating vector movmsk/ptest comparisons with zero if we can just use scalar OR instead, but this doesn't make sense for 256-bit or larger vectors which creates a more complex OR chain. This more closely matches what we do for icmp_ne/eq against non-zero values. I'm hoping that we can eventually allow even larger vectors to be handled with a OR/AND chains - but for now this just allows us to handle legal 256/512-bit vector widths. Full diff: https://github.com/llvm/llvm-project/pull/163373.diff 2 Files Affected:
diff --git a/llvm/lib/Target/X86/X86ISelLowering.cpp b/llvm/lib/Target/X86/X86ISelLowering.cpp
index eea84a2841764..edaf20a1aa436 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -22856,7 +22856,7 @@ static SDValue combineVectorSizedSetCCEquality(EVT VT, SDValue X, SDValue Y,
// be generated by the memcmp expansion pass with oversized integer compares
// (see PR33325).
bool IsOrXorXorTreeCCZero = isNullConstant(Y) && isOrXorXorTree(X);
- if (isNullConstant(Y) && !IsOrXorXorTreeCCZero)
+ if (isNullConstant(Y) && OpSize == 128 && !IsOrXorXorTreeCCZero)
return SDValue();
// Don't perform this combine if constructing the vector will be expensive.
diff --git a/llvm/test/CodeGen/X86/setcc-wide-types.ll b/llvm/test/CodeGen/X86/setcc-wide-types.ll
index 69abf6e0bec35..d018c535ea8f7 100644
--- a/llvm/test/CodeGen/X86/setcc-wide-types.ll
+++ b/llvm/test/CodeGen/X86/setcc-wide-types.ll
@@ -1493,15 +1493,23 @@ define i1 @allbits_i128_load_arg(ptr %w) {
}
define i1 @anybits_i256_load_arg(ptr %w) {
-; ANY-LABEL: anybits_i256_load_arg:
-; ANY: # %bb.0:
-; ANY-NEXT: movq (%rdi), %rax
-; ANY-NEXT: movq 8(%rdi), %rcx
-; ANY-NEXT: orq 24(%rdi), %rcx
-; ANY-NEXT: orq 16(%rdi), %rax
-; ANY-NEXT: orq %rcx, %rax
-; ANY-NEXT: setne %al
-; ANY-NEXT: retq
+; SSE-LABEL: anybits_i256_load_arg:
+; SSE: # %bb.0:
+; SSE-NEXT: movq (%rdi), %rax
+; SSE-NEXT: movq 8(%rdi), %rcx
+; SSE-NEXT: orq 24(%rdi), %rcx
+; SSE-NEXT: orq 16(%rdi), %rax
+; SSE-NEXT: orq %rcx, %rax
+; SSE-NEXT: setne %al
+; SSE-NEXT: retq
+;
+; AVXANY-LABEL: anybits_i256_load_arg:
+; AVXANY: # %bb.0:
+; AVXANY-NEXT: vmovdqu (%rdi), %ymm0
+; AVXANY-NEXT: vptest %ymm0, %ymm0
+; AVXANY-NEXT: setne %al
+; AVXANY-NEXT: vzeroupper
+; AVXANY-NEXT: retq
%ld = load i256, ptr %w
%cmp = icmp ne i256 %ld, 0
ret i1 %cmp
@@ -1552,21 +1560,30 @@ define i1 @allbits_i256_load_arg(ptr %w) {
}
define i1 @anybits_i512_load_arg(ptr %w) {
-; ANY-LABEL: anybits_i512_load_arg:
-; ANY: # %bb.0:
-; ANY-NEXT: movq 16(%rdi), %rax
-; ANY-NEXT: movq (%rdi), %rcx
-; ANY-NEXT: movq 8(%rdi), %rdx
-; ANY-NEXT: movq 24(%rdi), %rsi
-; ANY-NEXT: orq 56(%rdi), %rsi
-; ANY-NEXT: orq 40(%rdi), %rdx
-; ANY-NEXT: orq %rsi, %rdx
-; ANY-NEXT: orq 48(%rdi), %rax
-; ANY-NEXT: orq 32(%rdi), %rcx
-; ANY-NEXT: orq %rax, %rcx
-; ANY-NEXT: orq %rdx, %rcx
-; ANY-NEXT: setne %al
-; ANY-NEXT: retq
+; NO512-LABEL: anybits_i512_load_arg:
+; NO512: # %bb.0:
+; NO512-NEXT: movq 16(%rdi), %rax
+; NO512-NEXT: movq (%rdi), %rcx
+; NO512-NEXT: movq 8(%rdi), %rdx
+; NO512-NEXT: movq 24(%rdi), %rsi
+; NO512-NEXT: orq 56(%rdi), %rsi
+; NO512-NEXT: orq 40(%rdi), %rdx
+; NO512-NEXT: orq %rsi, %rdx
+; NO512-NEXT: orq 48(%rdi), %rax
+; NO512-NEXT: orq 32(%rdi), %rcx
+; NO512-NEXT: orq %rax, %rcx
+; NO512-NEXT: orq %rdx, %rcx
+; NO512-NEXT: setne %al
+; NO512-NEXT: retq
+;
+; AVX512-LABEL: anybits_i512_load_arg:
+; AVX512: # %bb.0:
+; AVX512-NEXT: vmovdqu64 (%rdi), %zmm0
+; AVX512-NEXT: vptestmd %zmm0, %zmm0, %k0
+; AVX512-NEXT: kortestw %k0, %k0
+; AVX512-NEXT: setne %al
+; AVX512-NEXT: vzeroupper
+; AVX512-NEXT: retq
%ld = load i512, ptr %w
%cmp = icmp ne i512 %ld, 0
ret i1 %cmp
|
phoebewang
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
…_ne/eq zero comparisons (llvm#163373) We avoid creating vector movmsk/ptest comparisons with zero if we can just use scalar OR instead, but this doesn't make sense for 256-bit or larger vectors which creates a more complex OR chain. This more closely matches what we do for icmp_ne/eq against non-zero values. I'm hoping that we can eventually allow even larger vectors to be handled with a OR/AND chains - but for now this just allows us to handle legal 256/512-bit vector widths.
We avoid creating vector movmsk/ptest comparisons with zero if we can just use scalar OR instead, but this doesn't make sense for 256-bit or larger vectors which creates a more complex OR chain.
This more closely matches what we do for icmp_ne/eq against non-zero values.
I'm hoping that we can eventually allow even larger vectors to be handled with a OR/AND chains - but for now this just allows us to handle legal 256/512-bit vector widths.