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/vshift-6.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

106 lines
3.9 KiB
LLVM
Raw Normal View History

[X86][SSE] Regenerate vshift tests llvm-svn: 277278
2016-07-31 04:28:02 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=i686-unknown -mattr=+sse2 | FileCheck %s --check-prefix=CHECK --check-prefix=X32
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+sse2 | FileCheck %s --check-prefix=CHECK --check-prefix=X64
[X86] Fix assertion failure caused by a wrong folding of vector shifts by immediate count. This fixes a regression intruced by r198113. Revision r198113 introduced an algorithm that tries to fold a vector shift by immediate count into a build_vector if the input vector is a known vector of constants. However the algorithm only worked under the assumption that the input vector type and the shift type are exactly the same. This patch disables the folding of vector shift by immediate count if the input vector type and the shift value type are not the same. llvm-svn: 199213
2014-01-14 21:17:12 +08:00
; This test makes sure that the compiler does not crash with an
; assertion failure when trying to fold a vector shift left
; by immediate count if the type of the input vector is different
; to the result type.
;
; This happens for example when lowering a shift left of a MVT::v16i8 vector.
; This is custom lowered into the following sequence:
; count << 5
; A = VSHLI(MVT::v8i16, r & (char16)15, 4)
; B = BITCAST MVT::v16i8, A
; VSELECT(r, B, count);
; count += count
; C = VSHLI(MVT::v8i16, r & (char16)63, 2)
; D = BITCAST MVT::v16i8, C
; r = VSELECT(r, C, count);
; count += count
; VSELECT(r, r+r, count);
; count = count << 5;
;
; Where 'r' is a vector of type MVT::v16i8, and
; 'count' is the vector shift count.
define <16 x i8> @do_not_crash(i8*, i32*, i64*, i32, i64, i8) {
[X86][SSE] Regenerate vshift tests llvm-svn: 277278
2016-07-31 04:28:02 +08:00
; X32-LABEL: do_not_crash:
[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: # %entry
[X86][SSE] Regenerate vshift tests llvm-svn: 277278
2016-07-31 04:28:02 +08:00
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movb %al, (%ecx)
; X32-NEXT: movd %eax, %xmm0
; X32-NEXT: psllq $56, %xmm0
; X32-NEXT: movdqa {{.*#+}} xmm2 = [255,255,255,255,255,255,255,0,255,255,255,255,255,255,255,255]
; X32-NEXT: movdqa %xmm2, %xmm1
; X32-NEXT: pandn %xmm0, %xmm1
; X32-NEXT: por %xmm2, %xmm1
; X32-NEXT: pcmpeqd %xmm2, %xmm2
; X32-NEXT: psllw $5, %xmm1
; X32-NEXT: pxor %xmm3, %xmm3
; X32-NEXT: pxor %xmm0, %xmm0
; X32-NEXT: pcmpgtb %xmm1, %xmm0
; X32-NEXT: pxor %xmm0, %xmm2
; X32-NEXT: pand {{\.LCPI.*}}, %xmm0
; X32-NEXT: por %xmm2, %xmm0
; X32-NEXT: paddb %xmm1, %xmm1
; X32-NEXT: pxor %xmm2, %xmm2
; X32-NEXT: pcmpgtb %xmm1, %xmm2
; X32-NEXT: movdqa %xmm2, %xmm4
; X32-NEXT: pandn %xmm0, %xmm4
; X32-NEXT: psllw $2, %xmm0
; X32-NEXT: pand %xmm2, %xmm0
[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-NEXT: pand {{\.LCPI.*}}, %xmm0
[X86][SSE] Regenerate vshift tests llvm-svn: 277278
2016-07-31 04:28:02 +08:00
; X32-NEXT: por %xmm4, %xmm0
; X32-NEXT: paddb %xmm1, %xmm1
; X32-NEXT: pcmpgtb %xmm1, %xmm3
; X32-NEXT: movdqa %xmm3, %xmm1
; X32-NEXT: pandn %xmm0, %xmm1
; X32-NEXT: paddb %xmm0, %xmm0
; X32-NEXT: pand %xmm3, %xmm0
; X32-NEXT: por %xmm1, %xmm0
; X32-NEXT: retl
;
; X64-LABEL: do_not_crash:
[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: # %entry
[X86][SSE] Regenerate vshift tests llvm-svn: 277278
2016-07-31 04:28:02 +08:00
; X64-NEXT: movb %r9b, (%rdi)
; X64-NEXT: movd %r9d, %xmm0
; X64-NEXT: psllq $56, %xmm0
; X64-NEXT: movdqa {{.*#+}} xmm2 = [255,255,255,255,255,255,255,0,255,255,255,255,255,255,255,255]
; X64-NEXT: movdqa %xmm2, %xmm1
; X64-NEXT: pandn %xmm0, %xmm1
; X64-NEXT: por %xmm2, %xmm1
; X64-NEXT: pcmpeqd %xmm2, %xmm2
; X64-NEXT: psllw $5, %xmm1
; X64-NEXT: pxor %xmm3, %xmm3
; X64-NEXT: pxor %xmm0, %xmm0
; X64-NEXT: pcmpgtb %xmm1, %xmm0
; X64-NEXT: pxor %xmm0, %xmm2
; X64-NEXT: pand {{.*}}(%rip), %xmm0
; X64-NEXT: por %xmm2, %xmm0
; X64-NEXT: paddb %xmm1, %xmm1
; X64-NEXT: pxor %xmm2, %xmm2
; X64-NEXT: pcmpgtb %xmm1, %xmm2
; X64-NEXT: movdqa %xmm2, %xmm4
; X64-NEXT: pandn %xmm0, %xmm4
; X64-NEXT: psllw $2, %xmm0
; X64-NEXT: pand %xmm2, %xmm0
[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-NEXT: pand {{.*}}(%rip), %xmm0
[X86][SSE] Regenerate vshift tests llvm-svn: 277278
2016-07-31 04:28:02 +08:00
; X64-NEXT: por %xmm4, %xmm0
; X64-NEXT: paddb %xmm1, %xmm1
; X64-NEXT: pcmpgtb %xmm1, %xmm3
; X64-NEXT: movdqa %xmm3, %xmm1
; X64-NEXT: pandn %xmm0, %xmm1
; X64-NEXT: paddb %xmm0, %xmm0
; X64-NEXT: pand %xmm3, %xmm0
; X64-NEXT: por %xmm1, %xmm0
; X64-NEXT: retq
[X86] Fix assertion failure caused by a wrong folding of vector shifts by immediate count. This fixes a regression intruced by r198113. Revision r198113 introduced an algorithm that tries to fold a vector shift by immediate count into a build_vector if the input vector is a known vector of constants. However the algorithm only worked under the assumption that the input vector type and the shift type are exactly the same. This patch disables the folding of vector shift by immediate count if the input vector type and the shift value type are not the same. llvm-svn: 199213
2014-01-14 21:17:12 +08:00
entry:
store i8 %5, i8* %0
[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
%L5 = load i8, i8* %0
[X86] Fix assertion failure caused by a wrong folding of vector shifts by immediate count. This fixes a regression intruced by r198113. Revision r198113 introduced an algorithm that tries to fold a vector shift by immediate count into a build_vector if the input vector is a known vector of constants. However the algorithm only worked under the assumption that the input vector type and the shift type are exactly the same. This patch disables the folding of vector shift by immediate count if the input vector type and the shift value type are not the same. llvm-svn: 199213
2014-01-14 21:17:12 +08:00
%I8 = insertelement <16 x i8> <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>, i8 %L5, i32 7
%B51 = shl <16 x i8> <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>, %I8
ret <16 x i8> %B51
}