2017-12-27 06:22:57 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
2018-01-20 01:50:25 +08:00
|
|
|
; RUN: llc -mtriple=x86_64-linux -mattr=+sse2 < %s | FileCheck %s --check-prefixes=LIN,LIN-SSE2
|
|
|
|
|
; RUN: llc -mtriple=x86_64-linux -mcpu=nehalem < %s | FileCheck %s --check-prefixes=LIN,LIN-SSE4
|
|
|
|
|
; RUN: llc -mtriple=x86_64-win32 -mattr=+sse2 < %s | FileCheck %s --check-prefixes=WIN,WIN-SSE2
|
|
|
|
|
; RUN: llc -mtriple=x86_64-win32 -mcpu=nehalem < %s | FileCheck %s --check-prefixes=WIN,WIN-SSE4
|
2014-12-04 21:49:51 +08:00
|
|
|
; RUN: llc -mtriple=i686-win32 -mcpu=nehalem < %s | FileCheck %s --check-prefix=LIN32
|
2010-03-17 03:08:20 +08:00
|
|
|
; rdar://7398554
|
2010-03-16 07:23:03 +08:00
|
|
|
|
|
|
|
|
; When doing vector gather-scatter index calculation with 32-bit indices,
|
2018-01-27 01:11:34 +08:00
|
|
|
; minimize shuffling of each individual element out of the index vector.
|
2010-03-16 07:23:03 +08:00
|
|
|
|
|
|
|
|
define <4 x double> @foo(double* %p, <4 x i32>* %i, <4 x i32>* %h) nounwind {
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-LABEL: foo:
|
|
|
|
|
; LIN-SSE2: # %bb.0:
|
|
|
|
|
; LIN-SSE2-NEXT: movdqa (%rsi), %xmm0
|
|
|
|
|
; LIN-SSE2-NEXT: pand (%rdx), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN-SSE2-NEXT: movd %xmm0, %eax
|
|
|
|
|
; LIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
|
; LIN-SSE2-NEXT: movd %xmm1, %ecx
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN-SSE2-NEXT: movd %xmm1, %edx
|
|
|
|
|
; LIN-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[3,1,2,3]
|
|
|
|
|
; LIN-SSE2-NEXT: movd %xmm0, %esi
|
|
|
|
|
; LIN-SSE2-NEXT: cltq
|
|
|
|
|
; LIN-SSE2-NEXT: movslq %ecx, %rcx
|
|
|
|
|
; LIN-SSE2-NEXT: movslq %edx, %rdx
|
|
|
|
|
; LIN-SSE2-NEXT: movslq %esi, %rsi
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; LIN-SSE2-NEXT: movhps {{.*#+}} xmm0 = xmm0[0,1],mem[0,1]
|
2019-07-03 01:51:02 +08:00
|
|
|
; LIN-SSE2-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; LIN-SSE2-NEXT: movhps {{.*#+}} xmm1 = xmm1[0,1],mem[0,1]
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-NEXT: retq
|
2017-12-27 06:22:57 +08:00
|
|
|
;
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE4-LABEL: foo:
|
|
|
|
|
; LIN-SSE4: # %bb.0:
|
|
|
|
|
; LIN-SSE4-NEXT: movdqa (%rsi), %xmm0
|
|
|
|
|
; LIN-SSE4-NEXT: pand (%rdx), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN-SSE4-NEXT: movd %xmm0, %eax
|
|
|
|
|
; LIN-SSE4-NEXT: pextrd $1, %xmm0, %ecx
|
|
|
|
|
; LIN-SSE4-NEXT: pextrd $2, %xmm0, %edx
|
|
|
|
|
; LIN-SSE4-NEXT: pextrd $3, %xmm0, %esi
|
|
|
|
|
; LIN-SSE4-NEXT: cltq
|
|
|
|
|
; LIN-SSE4-NEXT: movslq %ecx, %rcx
|
|
|
|
|
; LIN-SSE4-NEXT: movslq %edx, %rdx
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE4-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; LIN-SSE4-NEXT: movhps {{.*#+}} xmm0 = xmm0[0,1],mem[0,1]
|
2019-07-03 01:51:02 +08:00
|
|
|
; LIN-SSE4-NEXT: movslq %esi, %rax
|
|
|
|
|
; LIN-SSE4-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; LIN-SSE4-NEXT: movhps {{.*#+}} xmm1 = xmm1[0,1],mem[0,1]
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE4-NEXT: retq
|
|
|
|
|
;
|
|
|
|
|
; WIN-SSE2-LABEL: foo:
|
|
|
|
|
; WIN-SSE2: # %bb.0:
|
|
|
|
|
; WIN-SSE2-NEXT: movdqa (%rdx), %xmm0
|
|
|
|
|
; WIN-SSE2-NEXT: pand (%r8), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE2-NEXT: movd %xmm0, %r8d
|
|
|
|
|
; WIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
|
; WIN-SSE2-NEXT: movd %xmm1, %r9d
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE2-NEXT: movd %xmm1, %r10d
|
|
|
|
|
; WIN-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[3,1,2,3]
|
|
|
|
|
; WIN-SSE2-NEXT: movd %xmm0, %edx
|
2019-07-03 01:51:02 +08:00
|
|
|
; WIN-SSE2-NEXT: movslq %r8d, %rax
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE2-NEXT: movslq %r9d, %r8
|
2019-07-03 01:51:02 +08:00
|
|
|
; WIN-SSE2-NEXT: movslq %r10d, %r9
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE2-NEXT: movslq %edx, %rdx
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE2-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; WIN-SSE2-NEXT: movhps {{.*#+}} xmm0 = xmm0[0,1],mem[0,1]
|
2019-07-03 01:51:02 +08:00
|
|
|
; WIN-SSE2-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; WIN-SSE2-NEXT: movhps {{.*#+}} xmm1 = xmm1[0,1],mem[0,1]
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE2-NEXT: retq
|
|
|
|
|
;
|
|
|
|
|
; WIN-SSE4-LABEL: foo:
|
|
|
|
|
; WIN-SSE4: # %bb.0:
|
|
|
|
|
; WIN-SSE4-NEXT: movdqa (%rdx), %xmm0
|
|
|
|
|
; WIN-SSE4-NEXT: pand (%r8), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE4-NEXT: movd %xmm0, %eax
|
|
|
|
|
; WIN-SSE4-NEXT: pextrd $1, %xmm0, %edx
|
|
|
|
|
; WIN-SSE4-NEXT: pextrd $2, %xmm0, %r8d
|
|
|
|
|
; WIN-SSE4-NEXT: pextrd $3, %xmm0, %r9d
|
|
|
|
|
; WIN-SSE4-NEXT: cltq
|
2019-07-03 01:51:02 +08:00
|
|
|
; WIN-SSE4-NEXT: movslq %edx, %rdx
|
|
|
|
|
; WIN-SSE4-NEXT: movslq %r8d, %r8
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE4-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; WIN-SSE4-NEXT: movhps {{.*#+}} xmm0 = xmm0[0,1],mem[0,1]
|
2019-07-03 01:51:02 +08:00
|
|
|
; WIN-SSE4-NEXT: movslq %r9d, %rax
|
|
|
|
|
; WIN-SSE4-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; WIN-SSE4-NEXT: movhps {{.*#+}} xmm1 = xmm1[0,1],mem[0,1]
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE4-NEXT: retq
|
2017-12-27 06:22:57 +08:00
|
|
|
;
|
|
|
|
|
; LIN32-LABEL: foo:
|
|
|
|
|
; LIN32: # %bb.0:
|
|
|
|
|
; LIN32-NEXT: pushl %edi
|
|
|
|
|
; LIN32-NEXT: pushl %esi
|
|
|
|
|
; LIN32-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
|
|
|
; LIN32-NEXT: movl {{[0-9]+}}(%esp), %ecx
|
|
|
|
|
; LIN32-NEXT: movl {{[0-9]+}}(%esp), %edx
|
|
|
|
|
; LIN32-NEXT: movdqa (%edx), %xmm0
|
|
|
|
|
; LIN32-NEXT: pand (%ecx), %xmm0
|
2019-07-03 01:51:02 +08:00
|
|
|
; LIN32-NEXT: pextrd $1, %xmm0, %ecx
|
|
|
|
|
; LIN32-NEXT: pextrd $2, %xmm0, %edx
|
|
|
|
|
; LIN32-NEXT: pextrd $3, %xmm0, %esi
|
|
|
|
|
; LIN32-NEXT: movd %xmm0, %edi
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; LIN32-NEXT: movhps {{.*#+}} xmm0 = xmm0[0,1],mem[0,1]
|
2019-07-03 01:51:02 +08:00
|
|
|
; LIN32-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
|
2019-07-07 01:59:51 +08:00
|
|
|
; LIN32-NEXT: movhps {{.*#+}} xmm1 = xmm1[0,1],mem[0,1]
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: popl %esi
|
|
|
|
|
; LIN32-NEXT: popl %edi
|
|
|
|
|
; LIN32-NEXT: retl
|
2015-02-28 05:17:42 +08:00
|
|
|
%a = load <4 x i32>, <4 x i32>* %i
|
|
|
|
|
%b = load <4 x i32>, <4 x i32>* %h
|
2010-03-16 07:23:03 +08:00
|
|
|
%j = and <4 x i32> %a, %b
|
|
|
|
|
%d0 = extractelement <4 x i32> %j, i32 0
|
|
|
|
|
%d1 = extractelement <4 x i32> %j, i32 1
|
|
|
|
|
%d2 = extractelement <4 x i32> %j, i32 2
|
|
|
|
|
%d3 = extractelement <4 x i32> %j, i32 3
|
[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction
One of several parallel first steps to remove the target type of pointers,
replacing them with a single opaque pointer type.
This adds an explicit type parameter to the gep instruction so that when the
first parameter becomes an opaque pointer type, the type to gep through is
still available to the instructions.
* This doesn't modify gep operators, only instructions (operators will be
handled separately)
* Textual IR changes only. Bitcode (including upgrade) and changing the
in-memory representation will be in separate changes.
* geps of vectors are transformed as:
getelementptr <4 x float*> %x, ...
->getelementptr float, <4 x float*> %x, ...
Then, once the opaque pointer type is introduced, this will ultimately look
like:
getelementptr float, <4 x ptr> %x
with the unambiguous interpretation that it is a vector of pointers to float.
* address spaces remain on the pointer, not the type:
getelementptr float addrspace(1)* %x
->getelementptr float, float addrspace(1)* %x
Then, eventually:
getelementptr float, ptr addrspace(1) %x
Importantly, the massive amount of test case churn has been automated by
same crappy python code. I had to manually update a few test cases that
wouldn't fit the script's model (r228970,r229196,r229197,r229198). The
python script just massages stdin and writes the result to stdout, I
then wrapped that in a shell script to handle replacing files, then
using the usual find+xargs to migrate all the files.
update.py:
import fileinput
import sys
import re
ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))")
normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))")
def conv(match, line):
if not match:
return line
line = match.groups()[0]
if len(match.groups()[5]) == 0:
line += match.groups()[2]
line += match.groups()[3]
line += ", "
line += match.groups()[1]
line += "\n"
return line
for line in sys.stdin:
if line.find("getelementptr ") == line.find("getelementptr inbounds"):
if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("):
line = conv(re.match(ibrep, line), line)
elif line.find("getelementptr ") != line.find("getelementptr ("):
line = conv(re.match(normrep, line), line)
sys.stdout.write(line)
apply.sh:
for name in "$@"
do
python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name"
rm -f "$name.tmp"
done
The actual commands:
From llvm/src:
find test/ -name *.ll | xargs ./apply.sh
From llvm/src/tools/clang:
find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}"
From llvm/src/tools/polly:
find test/ -name *.ll | xargs ./apply.sh
After that, check-all (with llvm, clang, clang-tools-extra, lld,
compiler-rt, and polly all checked out).
The extra 'rm' in the apply.sh script is due to a few files in clang's test
suite using interesting unicode stuff that my python script was throwing
exceptions on. None of those files needed to be migrated, so it seemed
sufficient to ignore those cases.
Reviewers: rafael, dexonsmith, grosser
Differential Revision: http://reviews.llvm.org/D7636
llvm-svn: 230786
2015-02-28 03:29:02 +08:00
|
|
|
%q0 = getelementptr double, double* %p, i32 %d0
|
|
|
|
|
%q1 = getelementptr double, double* %p, i32 %d1
|
|
|
|
|
%q2 = getelementptr double, double* %p, i32 %d2
|
|
|
|
|
%q3 = getelementptr double, double* %p, i32 %d3
|
2015-02-28 05:17:42 +08:00
|
|
|
%r0 = load double, double* %q0
|
|
|
|
|
%r1 = load double, double* %q1
|
|
|
|
|
%r2 = load double, double* %q2
|
|
|
|
|
%r3 = load double, double* %q3
|
2010-03-16 07:23:03 +08:00
|
|
|
%v0 = insertelement <4 x double> undef, double %r0, i32 0
|
|
|
|
|
%v1 = insertelement <4 x double> %v0, double %r1, i32 1
|
|
|
|
|
%v2 = insertelement <4 x double> %v1, double %r2, i32 2
|
|
|
|
|
%v3 = insertelement <4 x double> %v2, double %r3, i32 3
|
|
|
|
|
ret <4 x double> %v3
|
|
|
|
|
}
|
2014-12-04 21:49:51 +08:00
|
|
|
|
|
|
|
|
; Check that the sequence previously used above, which bounces the vector off the
|
|
|
|
|
; cache works for x86-32. Note that in this case it will not be used for index
|
|
|
|
|
; calculation, since indexes are 32-bit, not 64.
|
|
|
|
|
define <4 x i64> @old(double* %p, <4 x i32>* %i, <4 x i32>* %h, i64 %f) nounwind {
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-LABEL: old:
|
|
|
|
|
; LIN-SSE2: # %bb.0:
|
|
|
|
|
; LIN-SSE2-NEXT: movdqa (%rsi), %xmm0
|
|
|
|
|
; LIN-SSE2-NEXT: pand (%rdx), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN-SSE2-NEXT: movd %xmm0, %eax
|
|
|
|
|
; LIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
|
; LIN-SSE2-NEXT: movd %xmm1, %edx
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN-SSE2-NEXT: movd %xmm1, %esi
|
|
|
|
|
; LIN-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[3,1,2,3]
|
|
|
|
|
; LIN-SSE2-NEXT: movd %xmm0, %edi
|
2018-02-14 00:25:25 +08:00
|
|
|
; LIN-SSE2-NEXT: andl %ecx, %eax
|
|
|
|
|
; LIN-SSE2-NEXT: andl %ecx, %edx
|
|
|
|
|
; LIN-SSE2-NEXT: andl %ecx, %esi
|
|
|
|
|
; LIN-SSE2-NEXT: andl %ecx, %edi
|
[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
|
|
|
; LIN-SSE2-NEXT: movq %rax, %xmm0
|
|
|
|
|
; LIN-SSE2-NEXT: movq %rdx, %xmm1
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
|
[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
|
|
|
; LIN-SSE2-NEXT: movq %rdi, %xmm2
|
|
|
|
|
; LIN-SSE2-NEXT: movq %rsi, %xmm1
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
|
|
|
|
|
; LIN-SSE2-NEXT: retq
|
|
|
|
|
;
|
|
|
|
|
; LIN-SSE4-LABEL: old:
|
|
|
|
|
; LIN-SSE4: # %bb.0:
|
|
|
|
|
; LIN-SSE4-NEXT: movdqa (%rsi), %xmm0
|
|
|
|
|
; LIN-SSE4-NEXT: pand (%rdx), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN-SSE4-NEXT: movd %xmm0, %eax
|
|
|
|
|
; LIN-SSE4-NEXT: pextrd $1, %xmm0, %edx
|
|
|
|
|
; LIN-SSE4-NEXT: pextrd $2, %xmm0, %esi
|
|
|
|
|
; LIN-SSE4-NEXT: pextrd $3, %xmm0, %edi
|
2018-02-14 00:25:25 +08:00
|
|
|
; LIN-SSE4-NEXT: andl %ecx, %eax
|
|
|
|
|
; LIN-SSE4-NEXT: andl %ecx, %edx
|
|
|
|
|
; LIN-SSE4-NEXT: andl %ecx, %esi
|
|
|
|
|
; LIN-SSE4-NEXT: andl %ecx, %edi
|
[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
|
|
|
; LIN-SSE4-NEXT: movq %rdx, %xmm1
|
|
|
|
|
; LIN-SSE4-NEXT: movq %rax, %xmm0
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE4-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
|
[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
|
|
|
; LIN-SSE4-NEXT: movq %rdi, %xmm2
|
|
|
|
|
; LIN-SSE4-NEXT: movq %rsi, %xmm1
|
2018-01-20 01:50:25 +08:00
|
|
|
; LIN-SSE4-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
|
|
|
|
|
; LIN-SSE4-NEXT: retq
|
|
|
|
|
;
|
|
|
|
|
; WIN-SSE2-LABEL: old:
|
|
|
|
|
; WIN-SSE2: # %bb.0:
|
|
|
|
|
; WIN-SSE2-NEXT: movdqa (%rdx), %xmm0
|
|
|
|
|
; WIN-SSE2-NEXT: pand (%r8), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE2-NEXT: movd %xmm0, %eax
|
|
|
|
|
; WIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
|
|
|
|
|
; WIN-SSE2-NEXT: movd %xmm1, %ecx
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,3,0,1]
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE2-NEXT: movd %xmm1, %r8d
|
|
|
|
|
; WIN-SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[3,1,2,3]
|
|
|
|
|
; WIN-SSE2-NEXT: movd %xmm0, %edx
|
2018-02-14 00:25:25 +08:00
|
|
|
; WIN-SSE2-NEXT: andl %r9d, %eax
|
|
|
|
|
; WIN-SSE2-NEXT: andl %r9d, %ecx
|
|
|
|
|
; WIN-SSE2-NEXT: andl %r9d, %r8d
|
|
|
|
|
; WIN-SSE2-NEXT: andl %r9d, %edx
|
[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
|
|
|
; WIN-SSE2-NEXT: movq %rax, %xmm0
|
|
|
|
|
; WIN-SSE2-NEXT: movq %rcx, %xmm1
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
|
[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
|
|
|
; WIN-SSE2-NEXT: movq %rdx, %xmm2
|
|
|
|
|
; WIN-SSE2-NEXT: movq %r8, %xmm1
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
|
|
|
|
|
; WIN-SSE2-NEXT: retq
|
2017-12-27 06:22:57 +08:00
|
|
|
;
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE4-LABEL: old:
|
|
|
|
|
; WIN-SSE4: # %bb.0:
|
|
|
|
|
; WIN-SSE4-NEXT: movdqa (%rdx), %xmm0
|
|
|
|
|
; WIN-SSE4-NEXT: pand (%r8), %xmm0
|
2018-01-27 01:11:34 +08:00
|
|
|
; WIN-SSE4-NEXT: movd %xmm0, %eax
|
|
|
|
|
; WIN-SSE4-NEXT: pextrd $1, %xmm0, %ecx
|
|
|
|
|
; WIN-SSE4-NEXT: pextrd $2, %xmm0, %r8d
|
|
|
|
|
; WIN-SSE4-NEXT: pextrd $3, %xmm0, %edx
|
2018-02-14 00:25:25 +08:00
|
|
|
; WIN-SSE4-NEXT: andl %r9d, %eax
|
|
|
|
|
; WIN-SSE4-NEXT: andl %r9d, %ecx
|
|
|
|
|
; WIN-SSE4-NEXT: andl %r9d, %r8d
|
|
|
|
|
; WIN-SSE4-NEXT: andl %r9d, %edx
|
[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
|
|
|
; WIN-SSE4-NEXT: movq %rcx, %xmm1
|
|
|
|
|
; WIN-SSE4-NEXT: movq %rax, %xmm0
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE4-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
|
[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
|
|
|
; WIN-SSE4-NEXT: movq %rdx, %xmm2
|
|
|
|
|
; WIN-SSE4-NEXT: movq %r8, %xmm1
|
2018-01-20 01:50:25 +08:00
|
|
|
; WIN-SSE4-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
|
|
|
|
|
; WIN-SSE4-NEXT: retq
|
2017-12-27 06:22:57 +08:00
|
|
|
;
|
|
|
|
|
; LIN32-LABEL: old:
|
|
|
|
|
; LIN32: # %bb.0:
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN32-NEXT: pushl %edi
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: pushl %esi
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN32-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
|
|
|
; LIN32-NEXT: movl {{[0-9]+}}(%esp), %ecx
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: movl {{[0-9]+}}(%esp), %edx
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN32-NEXT: movdqa (%edx), %xmm0
|
|
|
|
|
; LIN32-NEXT: pand (%ecx), %xmm0
|
|
|
|
|
; LIN32-NEXT: movd %xmm0, %ecx
|
|
|
|
|
; LIN32-NEXT: pextrd $1, %xmm0, %edx
|
|
|
|
|
; LIN32-NEXT: pextrd $2, %xmm0, %esi
|
|
|
|
|
; LIN32-NEXT: pextrd $3, %xmm0, %edi
|
|
|
|
|
; LIN32-NEXT: andl %eax, %ecx
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: andl %eax, %edx
|
|
|
|
|
; LIN32-NEXT: andl %eax, %esi
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN32-NEXT: andl %eax, %edi
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: movd %edx, %xmm1
|
|
|
|
|
; LIN32-NEXT: movd %ecx, %xmm0
|
|
|
|
|
; LIN32-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN32-NEXT: movd %edi, %xmm2
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: movd %esi, %xmm1
|
|
|
|
|
; LIN32-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
|
|
|
|
|
; LIN32-NEXT: popl %esi
|
2018-01-27 01:11:34 +08:00
|
|
|
; LIN32-NEXT: popl %edi
|
2017-12-27 06:22:57 +08:00
|
|
|
; LIN32-NEXT: retl
|
2015-02-28 05:17:42 +08:00
|
|
|
%a = load <4 x i32>, <4 x i32>* %i
|
|
|
|
|
%b = load <4 x i32>, <4 x i32>* %h
|
2014-12-04 21:49:51 +08:00
|
|
|
%j = and <4 x i32> %a, %b
|
|
|
|
|
%d0 = extractelement <4 x i32> %j, i32 0
|
|
|
|
|
%d1 = extractelement <4 x i32> %j, i32 1
|
|
|
|
|
%d2 = extractelement <4 x i32> %j, i32 2
|
|
|
|
|
%d3 = extractelement <4 x i32> %j, i32 3
|
|
|
|
|
%q0 = zext i32 %d0 to i64
|
|
|
|
|
%q1 = zext i32 %d1 to i64
|
|
|
|
|
%q2 = zext i32 %d2 to i64
|
2017-12-27 06:22:57 +08:00
|
|
|
%q3 = zext i32 %d3 to i64
|
2014-12-04 21:49:51 +08:00
|
|
|
%r0 = and i64 %q0, %f
|
|
|
|
|
%r1 = and i64 %q1, %f
|
|
|
|
|
%r2 = and i64 %q2, %f
|
|
|
|
|
%r3 = and i64 %q3, %f
|
|
|
|
|
%v0 = insertelement <4 x i64> undef, i64 %r0, i32 0
|
|
|
|
|
%v1 = insertelement <4 x i64> %v0, i64 %r1, i32 1
|
|
|
|
|
%v2 = insertelement <4 x i64> %v1, i64 %r2, i32 2
|
|
|
|
|
%v3 = insertelement <4 x i64> %v2, i64 %r3, i32 3
|
|
|
|
|
ret <4 x i64> %v3
|
|
|
|
|
}
|