maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/v8i1-masks.ll

166 lines
6.2 KiB
LLVM
Raw Normal View History

[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+avx | FileCheck %s --check-prefix=CHECK --check-prefix=X32
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+avx | FileCheck %s --check-prefix=CHECK --check-prefix=X64
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
; RUN: llc < %s -mtriple=i686-apple-darwin -mattr=+avx2 | FileCheck %s --check-prefix=CHECK --check-prefix=X32-AVX2
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mattr=+avx2 | FileCheck %s --check-prefix=CHECK --check-prefix=X64-AVX2
On AVX/AVX2 the type v8i1 is legalized to v8i16, which is an XMM sized register. In most cases we actually compare or select YMM-sized registers and mixing the two types creates horrible code. This commit optimizes some of the transition sequences. PR14657. llvm-svn: 171148
2012-12-27 16:15:45 +08:00
define void @and_masks(<8 x float>* %a, <8 x float>* %b, <8 x float>* %c) nounwind uwtable noinline ssp {
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X32-LABEL: and_masks:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; X32: ## %bb.0:
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NEXT: vmovups (%edx), %ymm0
; X32-NEXT: vmovups (%ecx), %ymm1
; X32-NEXT: vcmpltps %ymm0, %ymm1, %ymm1
; X32-NEXT: vmovups (%eax), %ymm2
; X32-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
; X32-NEXT: vandps %ymm1, %ymm0, %ymm0
[X86] Remove unnecessary bitcast from the front of AVX1Only 256-bit logical operation patterns. llvm-svn: 278088
2016-08-09 11:06:26 +08:00
; X32-NEXT: vandps LCPI0_0, %ymm0, %ymm0
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X32-NEXT: vmovaps %ymm0, (%eax)
; X32-NEXT: vzeroupper
; X32-NEXT: retl
;
; X64-LABEL: and_masks:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; X64: ## %bb.0:
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X64-NEXT: vmovups (%rdi), %ymm0
; X64-NEXT: vmovups (%rsi), %ymm1
; X64-NEXT: vcmpltps %ymm0, %ymm1, %ymm1
; X64-NEXT: vmovups (%rdx), %ymm2
; X64-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
; X64-NEXT: vandps %ymm1, %ymm0, %ymm0
[X86] Remove unnecessary bitcast from the front of AVX1Only 256-bit logical operation patterns. llvm-svn: 278088
2016-08-09 11:06:26 +08:00
; X64-NEXT: vandps {{.*}}(%rip), %ymm0, %ymm0
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X64-NEXT: vmovaps %ymm0, (%rax)
; X64-NEXT: vzeroupper
; X64-NEXT: retq
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
;
; X32-AVX2-LABEL: and_masks:
; X32-AVX2: ## %bb.0:
; X32-AVX2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-AVX2-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-AVX2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-AVX2-NEXT: vmovups (%edx), %ymm0
; X32-AVX2-NEXT: vmovups (%ecx), %ymm1
; X32-AVX2-NEXT: vcmpltps %ymm0, %ymm1, %ymm1
; X32-AVX2-NEXT: vmovups (%eax), %ymm2
; X32-AVX2-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
; X32-AVX2-NEXT: vandps %ymm1, %ymm0, %ymm0
[X86] Move promotion of vector and/or/xor from legalization to DAG combine Summary: I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that. This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better. In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53107 llvm-svn: 344487
2018-10-15 09:51:58 +08:00
; X32-AVX2-NEXT: vpsrld $31, %ymm0, %ymm0
; X32-AVX2-NEXT: vmovdqa %ymm0, (%eax)
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
; X32-AVX2-NEXT: vzeroupper
; X32-AVX2-NEXT: retl
;
; X64-AVX2-LABEL: and_masks:
; X64-AVX2: ## %bb.0:
; X64-AVX2-NEXT: vmovups (%rdi), %ymm0
; X64-AVX2-NEXT: vmovups (%rsi), %ymm1
; X64-AVX2-NEXT: vcmpltps %ymm0, %ymm1, %ymm1
; X64-AVX2-NEXT: vmovups (%rdx), %ymm2
; X64-AVX2-NEXT: vcmpltps %ymm0, %ymm2, %ymm0
; X64-AVX2-NEXT: vandps %ymm1, %ymm0, %ymm0
[X86] Move promotion of vector and/or/xor from legalization to DAG combine Summary: I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that. This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better. In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53107 llvm-svn: 344487
2018-10-15 09:51:58 +08:00
; X64-AVX2-NEXT: vpsrld $31, %ymm0, %ymm0
; X64-AVX2-NEXT: vmovdqa %ymm0, (%rax)
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
; X64-AVX2-NEXT: vzeroupper
; X64-AVX2-NEXT: retq
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%v0 = load <8 x float>, <8 x float>* %a, align 16
%v1 = load <8 x float>, <8 x float>* %b, align 16
On AVX/AVX2 the type v8i1 is legalized to v8i16, which is an XMM sized register. In most cases we actually compare or select YMM-sized registers and mixing the two types creates horrible code. This commit optimizes some of the transition sequences. PR14657. llvm-svn: 171148
2012-12-27 16:15:45 +08:00
%m0 = fcmp olt <8 x float> %v1, %v0
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%v2 = load <8 x float>, <8 x float>* %c, align 16
On AVX/AVX2 the type v8i1 is legalized to v8i16, which is an XMM sized register. In most cases we actually compare or select YMM-sized registers and mixing the two types creates horrible code. This commit optimizes some of the transition sequences. PR14657. llvm-svn: 171148
2012-12-27 16:15:45 +08:00
%m1 = fcmp olt <8 x float> %v2, %v0
%mand = and <8 x i1> %m1, %m0
%r = zext <8 x i1> %mand to <8 x i32>
On Sandybridge split unaligned 256bit stores into two xmm-sized stores. llvm-svn: 172894
2013-01-19 16:38:41 +08:00
store <8 x i32> %r, <8 x i32>* undef, align 32
On AVX/AVX2 the type v8i1 is legalized to v8i16, which is an XMM sized register. In most cases we actually compare or select YMM-sized registers and mixing the two types creates horrible code. This commit optimizes some of the transition sequences. PR14657. llvm-svn: 171148
2012-12-27 16:15:45 +08:00
ret void
}
define void @neg_masks(<8 x float>* %a, <8 x float>* %b, <8 x float>* %c) nounwind uwtable noinline ssp {
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X32-LABEL: neg_masks:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; X32: ## %bb.0:
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: vmovups (%ecx), %ymm0
[TargetLowering] Fix undef vector element issue with true/false result handling Fixed an issue with vector usage of TargetLowering::isConstTrueVal / TargetLowering::isConstFalseVal boolean result matching. The comment said we shouldn't handle constant splat vectors with undef elements. But the the actual code was returning false if the build vector contained no undef elements.... This patch now ignores the number of undefs (getConstantSplatNode will return null if the build vector is all undefs). The change has also unearthed a couple of missed opportunities in AVX512 comparison code that will need to be addressed. Differential Revision: https://reviews.llvm.org/D26031 llvm-svn: 286238
2016-11-08 23:07:01 +08:00
; X32-NEXT: vcmpnltps (%eax), %ymm0, %ymm0
; X32-NEXT: vandps LCPI1_0, %ymm0, %ymm0
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X32-NEXT: vmovaps %ymm0, (%eax)
; X32-NEXT: vzeroupper
; X32-NEXT: retl
;
; X64-LABEL: neg_masks:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; X64: ## %bb.0:
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X64-NEXT: vmovups (%rsi), %ymm0
[TargetLowering] Fix undef vector element issue with true/false result handling Fixed an issue with vector usage of TargetLowering::isConstTrueVal / TargetLowering::isConstFalseVal boolean result matching. The comment said we shouldn't handle constant splat vectors with undef elements. But the the actual code was returning false if the build vector contained no undef elements.... This patch now ignores the number of undefs (getConstantSplatNode will return null if the build vector is all undefs). The change has also unearthed a couple of missed opportunities in AVX512 comparison code that will need to be addressed. Differential Revision: https://reviews.llvm.org/D26031 llvm-svn: 286238
2016-11-08 23:07:01 +08:00
; X64-NEXT: vcmpnltps (%rdi), %ymm0, %ymm0
; X64-NEXT: vandps {{.*}}(%rip), %ymm0, %ymm0
[X86][SSE] Regenerated comparison mask and float immediate tests llvm-svn: 265184
2016-04-02 05:00:00 +08:00
; X64-NEXT: vmovaps %ymm0, (%rax)
; X64-NEXT: vzeroupper
; X64-NEXT: retq
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
;
; X32-AVX2-LABEL: neg_masks:
; X32-AVX2: ## %bb.0:
; X32-AVX2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-AVX2-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-AVX2-NEXT: vmovups (%ecx), %ymm0
; X32-AVX2-NEXT: vcmpnltps (%eax), %ymm0, %ymm0
; X32-AVX2-NEXT: vbroadcastss {{.*#+}} ymm1 = [1,1,1,1,1,1,1,1]
; X32-AVX2-NEXT: vandps %ymm1, %ymm0, %ymm0
; X32-AVX2-NEXT: vmovaps %ymm0, (%eax)
; X32-AVX2-NEXT: vzeroupper
; X32-AVX2-NEXT: retl
;
; X64-AVX2-LABEL: neg_masks:
; X64-AVX2: ## %bb.0:
; X64-AVX2-NEXT: vmovups (%rsi), %ymm0
; X64-AVX2-NEXT: vcmpnltps (%rdi), %ymm0, %ymm0
; X64-AVX2-NEXT: vbroadcastss {{.*#+}} ymm1 = [1,1,1,1,1,1,1,1]
; X64-AVX2-NEXT: vandps %ymm1, %ymm0, %ymm0
; X64-AVX2-NEXT: vmovaps %ymm0, (%rax)
; X64-AVX2-NEXT: vzeroupper
; X64-AVX2-NEXT: retq
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%v0 = load <8 x float>, <8 x float>* %a, align 16
%v1 = load <8 x float>, <8 x float>* %b, align 16
On AVX/AVX2 the type v8i1 is legalized to v8i16, which is an XMM sized register. In most cases we actually compare or select YMM-sized registers and mixing the two types creates horrible code. This commit optimizes some of the transition sequences. PR14657. llvm-svn: 171148
2012-12-27 16:15:45 +08:00
%m0 = fcmp olt <8 x float> %v1, %v0
%mand = xor <8 x i1> %m0, <i1 1, i1 1, i1 1, i1 1, i1 1, i1 1, i1 1, i1 1>
%r = zext <8 x i1> %mand to <8 x i32>
On Sandybridge split unaligned 256bit stores into two xmm-sized stores. llvm-svn: 172894
2013-01-19 16:38:41 +08:00
store <8 x i32> %r, <8 x i32>* undef, align 32
On AVX/AVX2 the type v8i1 is legalized to v8i16, which is an XMM sized register. In most cases we actually compare or select YMM-sized registers and mixing the two types creates horrible code. This commit optimizes some of the transition sequences. PR14657. llvm-svn: 171148
2012-12-27 16:15:45 +08:00
ret void
}
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
define <8 x i32> @and_mask_constant(<8 x i32> %v0, <8 x i32> %v1) {
; X32-LABEL: and_mask_constant:
; X32: ## %bb.0:
; X32-NEXT: vextractf128 $1, %ymm0, %xmm1
; X32-NEXT: vpxor %xmm2, %xmm2, %xmm2
; X32-NEXT: vpcmpeqd %xmm2, %xmm1, %xmm1
; X32-NEXT: vpcmpeqd %xmm2, %xmm0, %xmm0
[X86] Don't emit *_extend_vector_inreg nodes when both the input and output types are legal with AVX1 We already have custom lowering for the AVX case in LegalizeVectorOps. So its better to keep the regular extend op around as long as possible. I had to qualify one place in DAG combine that created illegal vector extending load operations. This change by itself had no effect on any tests which is why its included here. I've made a few cleanups to the custom lowering. The sign extend code no longer creates an identity shuffle with undef elements. The zero extend code now emits a zero_extend_vector_inreg instead of an unpckl with a zero vector. For the high half of the custom lowering of zero_extend/any_extend, we're now using an unpckh with a zero vector or undef. Previously we used used a pshufd to move the upper 64-bits to the lower 64-bits and then used a zero_extend_vector_inreg. I think the zero vector should require less execution resources and be smaller code size. Differential Revision: https://reviews.llvm.org/D54024 llvm-svn: 346043
2018-11-03 05:09:49 +08:00
; X32-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; X32-NEXT: vandps LCPI2_0, %ymm0, %ymm0
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
; X32-NEXT: retl
;
; X64-LABEL: and_mask_constant:
; X64: ## %bb.0:
; X64-NEXT: vextractf128 $1, %ymm0, %xmm1
; X64-NEXT: vpxor %xmm2, %xmm2, %xmm2
; X64-NEXT: vpcmpeqd %xmm2, %xmm1, %xmm1
; X64-NEXT: vpcmpeqd %xmm2, %xmm0, %xmm0
[X86] Don't emit *_extend_vector_inreg nodes when both the input and output types are legal with AVX1 We already have custom lowering for the AVX case in LegalizeVectorOps. So its better to keep the regular extend op around as long as possible. I had to qualify one place in DAG combine that created illegal vector extending load operations. This change by itself had no effect on any tests which is why its included here. I've made a few cleanups to the custom lowering. The sign extend code no longer creates an identity shuffle with undef elements. The zero extend code now emits a zero_extend_vector_inreg instead of an unpckl with a zero vector. For the high half of the custom lowering of zero_extend/any_extend, we're now using an unpckh with a zero vector or undef. Previously we used used a pshufd to move the upper 64-bits to the lower 64-bits and then used a zero_extend_vector_inreg. I think the zero vector should require less execution resources and be smaller code size. Differential Revision: https://reviews.llvm.org/D54024 llvm-svn: 346043
2018-11-03 05:09:49 +08:00
; X64-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; X64-NEXT: vandps {{.*}}(%rip), %ymm0, %ymm0
[X86] Teach WidenMaskArithmetic to handle any constant buildvector on the RHS not just all zeros/ones. llvm-svn: 321415
2017-12-24 09:03:31 +08:00
; X64-NEXT: retq
;
; X32-AVX2-LABEL: and_mask_constant:
; X32-AVX2: ## %bb.0:
; X32-AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
; X32-AVX2-NEXT: vpcmpeqd %ymm1, %ymm0, %ymm0
; X32-AVX2-NEXT: vpand LCPI2_0, %ymm0, %ymm0
; X32-AVX2-NEXT: retl
;
; X64-AVX2-LABEL: and_mask_constant:
; X64-AVX2: ## %bb.0:
; X64-AVX2-NEXT: vpxor %xmm1, %xmm1, %xmm1
; X64-AVX2-NEXT: vpcmpeqd %ymm1, %ymm0, %ymm0
; X64-AVX2-NEXT: vpand {{.*}}(%rip), %ymm0, %ymm0
; X64-AVX2-NEXT: retq
%m = icmp eq <8 x i32> %v0, zeroinitializer
%mand = and <8 x i1> %m, <i1 true, i1 false, i1 false, i1 true, i1 false, i1 true, i1 true, i1 false>
%r = zext <8 x i1> %mand to <8 x i32>
ret <8 x i32> %r
}