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/SystemZ/vec-perm-13.ll

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

39 lines
1.6 KiB
LLVM
Raw Normal View History

[SystemZ] Fix another assertion failure in tryBuildVectorShuffle This fixes yet another scenario where tryBuildVectorShuffle would attempt to create a BUILD_VECTOR node with an invalid combination of types. This can happen if the incoming BUILD_VECTOR has elements of a type different from the vector element type, which is allowed in certain cases as long as they are all the same type. When one of these elements is used in the residual vector, and UNDEF elements are added to fill up the residual vector, those UNDEFs then have to use the type of the original element, not the vector element type, or else the resulting BUILD_VECTOR will have an invalid type combination. llvm-svn: 249706
2015-10-09 01:46:59 +08:00
; Test vector shuffles on vectors with implicitly extended elements
;
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 | \
; RUN: FileCheck -check-prefix=CHECK-CODE %s
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 | \
; RUN: FileCheck -check-prefix=CHECK-VECTOR %s
define <4 x i16> @f1(<4 x i16> %x) {
; CHECK-CODE-LABEL: f1:
; CHECK-CODE: larl [[REG:%r[0-5]]],
; CHECK-CODE: vl [[MASK:%v[0-9]+]], 0([[REG]])
; CHECK-CODE: vgbm [[ELT:%v[0-9]+]], 0
; CHECK-CODE: vperm %v24, %v24, [[ELT]], [[MASK]]
; CHECK-CODE: br %r14
; CHECK-VECTOR: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .byte 6
; CHECK-VECTOR-NEXT: .byte 7
[DAG] Remove isVectorClearMaskLegal() check from vector_build dagcombine This check currently doesn't seem to do anything useful on any in-tree target: On non-x86, it always evaluates to false, so we never hit the code path that creates the shuffle with zero. On x86, it just forwards to isShuffleMaskLegal(), which is a reasonable thing to query in general, but doesn't make sense if only restricted to zero blends. Differential Revision: https://reviews.llvm.org/D24625 llvm-svn: 282567
2016-09-28 14:13:58 +08:00
; CHECK-VECTOR-NEXT: .byte 22
; CHECK-VECTOR-NEXT: .byte 23
[SystemZ] Fix another assertion failure in tryBuildVectorShuffle This fixes yet another scenario where tryBuildVectorShuffle would attempt to create a BUILD_VECTOR node with an invalid combination of types. This can happen if the incoming BUILD_VECTOR has elements of a type different from the vector element type, which is allowed in certain cases as long as they are all the same type. When one of these elements is used in the residual vector, and UNDEF elements are added to fill up the residual vector, those UNDEFs then have to use the type of the original element, not the vector element type, or else the resulting BUILD_VECTOR will have an invalid type combination. llvm-svn: 249706
2015-10-09 01:46:59 +08:00
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
; CHECK-VECTOR-NEXT: .space 1
%elt = extractelement <4 x i16> %x, i32 3
%vec1 = insertelement <4 x i16> undef, i16 %elt, i32 2
%vec2 = insertelement <4 x i16> %vec1, i16 0, i32 3
ret <4 x i16> %vec2
}