2009-10-12 06:52:15 +08:00
|
|
|
; RUN: opt < %s -instcombine -S | FileCheck %s
|
2006-04-11 06:45:37 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
define <4 x float> @test1(<4 x float> %v1) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test1
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
; CHECK: ret <4 x float> %v1
|
|
|
|
|
%v2 = shufflevector <4 x float> %v1, <4 x float> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3>
|
|
|
|
|
ret <4 x float> %v2
|
2006-04-11 06:45:37 +08:00
|
|
|
}
|
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
define <4 x float> @test2(<4 x float> %v1) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test2
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
; CHECK: ret <4 x float> %v1
|
|
|
|
|
%v2 = shufflevector <4 x float> %v1, <4 x float> %v1, <4 x i32> <i32 0, i32 5, i32 2, i32 7>
|
|
|
|
|
ret <4 x float> %v2
|
2006-04-11 06:45:37 +08:00
|
|
|
}
|
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
define float @test3(<4 x float> %A, <4 x float> %B, float %f) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test3
|
|
|
|
|
; CHECK: ret float %f
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
%C = insertelement <4 x float> %A, float %f, i32 0
|
|
|
|
|
%D = shufflevector <4 x float> %C, <4 x float> %B, <4 x i32> <i32 5, i32 0, i32 2, i32 7>
|
|
|
|
|
%E = extractelement <4 x float> %D, i32 1
|
2006-04-11 07:06:18 +08:00
|
|
|
ret float %E
|
|
|
|
|
}
|
|
|
|
|
|
2007-01-26 16:25:06 +08:00
|
|
|
define i32 @test4(<4 x i32> %X) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test4
|
|
|
|
|
; CHECK-NEXT: extractelement
|
|
|
|
|
; CHECK-NEXT: ret
|
2007-01-05 15:34:41 +08:00
|
|
|
%tmp152.i53899.i = shufflevector <4 x i32> %X, <4 x i32> undef, <4 x i32> zeroinitializer
|
|
|
|
|
%tmp34 = extractelement <4 x i32> %tmp152.i53899.i, i32 0
|
|
|
|
|
ret i32 %tmp34
|
2006-05-26 06:52:49 +08:00
|
|
|
}
|
|
|
|
|
|
2007-01-26 16:25:06 +08:00
|
|
|
define i32 @test5(<4 x i32> %X) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test5
|
|
|
|
|
; CHECK-NEXT: extractelement
|
|
|
|
|
; CHECK-NEXT: ret
|
2007-01-05 15:34:41 +08:00
|
|
|
%tmp152.i53899.i = shufflevector <4 x i32> %X, <4 x i32> undef, <4 x i32> <i32 3, i32 2, i32 undef, i32 undef>
|
|
|
|
|
%tmp34 = extractelement <4 x i32> %tmp152.i53899.i, i32 0
|
|
|
|
|
ret i32 %tmp34
|
2006-05-26 06:52:49 +08:00
|
|
|
}
|
|
|
|
|
|
2007-01-26 16:25:06 +08:00
|
|
|
define float @test6(<4 x float> %X) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test6
|
|
|
|
|
; CHECK-NEXT: extractelement
|
|
|
|
|
; CHECK-NEXT: ret
|
2007-01-31 00:16:01 +08:00
|
|
|
%X1 = bitcast <4 x float> %X to <4 x i32>
|
|
|
|
|
%tmp152.i53899.i = shufflevector <4 x i32> %X1, <4 x i32> undef, <4 x i32> zeroinitializer
|
2007-01-05 15:34:41 +08:00
|
|
|
%tmp152.i53900.i = bitcast <4 x i32> %tmp152.i53899.i to <4 x float>
|
|
|
|
|
%tmp34 = extractelement <4 x float> %tmp152.i53900.i, i32 0
|
2006-05-26 07:23:22 +08:00
|
|
|
ret float %tmp34
|
|
|
|
|
}
|
|
|
|
|
|
2007-01-26 16:25:06 +08:00
|
|
|
define <4 x float> @test7(<4 x float> %tmp45.i) {
|
2009-10-12 06:52:15 +08:00
|
|
|
; CHECK: @test7
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
; CHECK-NEXT: ret <4 x float> %tmp45.i
|
2007-01-05 15:35:24 +08:00
|
|
|
%tmp1642.i = shufflevector <4 x float> %tmp45.i, <4 x float> undef, <4 x i32> < i32 0, i32 1, i32 6, i32 7 >
|
|
|
|
|
ret <4 x float> %tmp1642.i
|
|
|
|
|
}
|
2009-10-12 06:52:15 +08:00
|
|
|
|
|
|
|
|
; This should turn into a single shuffle.
|
|
|
|
|
define <4 x float> @test8(<4 x float> %tmp, <4 x float> %tmp1) {
|
|
|
|
|
; CHECK: @test8
|
|
|
|
|
; CHECK-NEXT: shufflevector
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp4 = extractelement <4 x float> %tmp, i32 1
|
|
|
|
|
%tmp2 = extractelement <4 x float> %tmp, i32 3
|
|
|
|
|
%tmp1.upgrd.1 = extractelement <4 x float> %tmp1, i32 0
|
|
|
|
|
%tmp128 = insertelement <4 x float> undef, float %tmp4, i32 0
|
|
|
|
|
%tmp130 = insertelement <4 x float> %tmp128, float undef, i32 1
|
|
|
|
|
%tmp132 = insertelement <4 x float> %tmp130, float %tmp2, i32 2
|
|
|
|
|
%tmp134 = insertelement <4 x float> %tmp132, float %tmp1.upgrd.1, i32 3
|
|
|
|
|
ret <4 x float> %tmp134
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-12 06:54:48 +08:00
|
|
|
; Test fold of two shuffles where the first shuffle vectors inputs are a
|
|
|
|
|
; different length then the second.
|
|
|
|
|
define <4 x i8> @test9(<16 x i8> %tmp6) nounwind {
|
|
|
|
|
; CHECK: @test9
|
|
|
|
|
; CHECK-NEXT: shufflevector
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp7 = shufflevector <16 x i8> %tmp6, <16 x i8> undef, <4 x i32> < i32 13, i32 9, i32 4, i32 13 > ; <<4 x i8>> [#uses=1]
|
|
|
|
|
%tmp9 = shufflevector <4 x i8> %tmp7, <4 x i8> undef, <4 x i32> < i32 3, i32 1, i32 2, i32 0 > ; <<4 x i8>> [#uses=1]
|
|
|
|
|
ret <4 x i8> %tmp9
|
2010-04-08 06:53:17 +08:00
|
|
|
}
|
2010-10-30 06:02:50 +08:00
|
|
|
|
2010-10-30 06:03:05 +08:00
|
|
|
; Same as test9, but make sure that "undef" mask values are not confused with
|
|
|
|
|
; mask values of 2*N, where N is the mask length. These shuffles should not
|
|
|
|
|
; be folded (because [8,9,4,8] may not be a mask supported by the target).
|
|
|
|
|
define <4 x i8> @test9a(<16 x i8> %tmp6) nounwind {
|
|
|
|
|
; CHECK: @test9a
|
|
|
|
|
; CHECK-NEXT: shufflevector
|
|
|
|
|
; CHECK-NEXT: shufflevector
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp7 = shufflevector <16 x i8> %tmp6, <16 x i8> undef, <4 x i32> < i32 undef, i32 9, i32 4, i32 8 > ; <<4 x i8>> [#uses=1]
|
|
|
|
|
%tmp9 = shufflevector <4 x i8> %tmp7, <4 x i8> undef, <4 x i32> < i32 3, i32 1, i32 2, i32 0 > ; <<4 x i8>> [#uses=1]
|
|
|
|
|
ret <4 x i8> %tmp9
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 03:06:29 +08:00
|
|
|
; Test fold of two shuffles where the first shuffle vectors inputs are a
|
|
|
|
|
; different length then the second.
|
|
|
|
|
define <4 x i8> @test9b(<4 x i8> %tmp6, <4 x i8> %tmp7) nounwind {
|
|
|
|
|
; CHECK: @test9
|
|
|
|
|
; CHECK-NEXT: shufflevector
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp1 = shufflevector <4 x i8> %tmp6, <4 x i8> %tmp7, <8 x i32> <i32 0, i32 1, i32 4, i32 5, i32 4, i32 5, i32 2, i32 3> ; <<4 x i8>> [#uses=1]
|
|
|
|
|
%tmp9 = shufflevector <8 x i8> %tmp1, <8 x i8> undef, <4 x i32> <i32 0, i32 1, i32 4, i32 5> ; <<4 x i8>> [#uses=1]
|
|
|
|
|
ret <4 x i8> %tmp9
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-30 06:02:50 +08:00
|
|
|
; Redundant vector splats should be removed. Radar 8597790.
|
|
|
|
|
define <4 x i32> @test10(<4 x i32> %tmp5) nounwind {
|
|
|
|
|
; CHECK: @test10
|
|
|
|
|
; CHECK-NEXT: shufflevector
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp6 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
|
|
|
|
|
%tmp7 = shufflevector <4 x i32> %tmp6, <4 x i32> undef, <4 x i32> zeroinitializer
|
|
|
|
|
ret <4 x i32> %tmp7
|
|
|
|
|
}
|
2011-10-22 03:06:29 +08:00
|
|
|
|
|
|
|
|
; Test fold of two shuffles where the two shufflevector inputs's op1 are
|
|
|
|
|
; the same
|
|
|
|
|
define <8 x i8> @test11(<16 x i8> %tmp6) nounwind {
|
|
|
|
|
; CHECK: @test11
|
|
|
|
|
; CHECK-NEXT: shufflevector <16 x i8> %tmp6, <16 x i8> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp1 = shufflevector <16 x i8> %tmp6, <16 x i8> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; <<4 x i8>> [#uses=1]
|
|
|
|
|
%tmp2 = shufflevector <16 x i8> %tmp6, <16 x i8> undef, <4 x i32> <i32 4, i32 5, i32 6, i32 7> ; <<4 x i8>> [#uses=1]
|
|
|
|
|
%tmp3 = shufflevector <4 x i8> %tmp1, <4 x i8> %tmp2, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7> ; <<8 x i8>> [#uses=1]
|
|
|
|
|
ret <8 x i8> %tmp3
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Test fold of two shuffles where the first shufflevector's inputs are
|
|
|
|
|
; the same as the second
|
|
|
|
|
define <8 x i8> @test12(<8 x i8> %tmp6, <8 x i8> %tmp2) nounwind {
|
|
|
|
|
; CHECK: @test12
|
|
|
|
|
; CHECK-NEXT: shufflevector <8 x i8> %tmp6, <8 x i8> %tmp2, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 9, i32 8, i32 11, i32 12>
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp1 = shufflevector <8 x i8> %tmp6, <8 x i8> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 5, i32 4, i32 undef, i32 7> ; <<8 x i8>> [#uses=1]
|
|
|
|
|
%tmp3 = shufflevector <8 x i8> %tmp1, <8 x i8> %tmp2, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 9, i32 8, i32 11, i32 12> ; <<8 x i8>> [#uses=1]
|
|
|
|
|
ret <8 x i8> %tmp3
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Test fold of two shuffles where the first shufflevector's inputs are
|
|
|
|
|
; the same as the second
|
|
|
|
|
define <8 x i8> @test12a(<8 x i8> %tmp6, <8 x i8> %tmp2) nounwind {
|
|
|
|
|
; CHECK: @test12a
|
|
|
|
|
; CHECK-NEXT: shufflevector <8 x i8> %tmp2, <8 x i8> %tmp6, <8 x i32> <i32 0, i32 3, i32 1, i32 4, i32 8, i32 9, i32 10, i32 11>
|
|
|
|
|
; CHECK-NEXT: ret
|
|
|
|
|
%tmp1 = shufflevector <8 x i8> %tmp6, <8 x i8> undef, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 5, i32 4, i32 undef, i32 7> ; <<8 x i8>> [#uses=1]
|
|
|
|
|
%tmp3 = shufflevector <8 x i8> %tmp2, <8 x i8> %tmp1, <8 x i32> <i32 0, i32 3, i32 1, i32 4, i32 8, i32 9, i32 10, i32 11> ; <<8 x i8>> [#uses=1]
|
|
|
|
|
ret <8 x i8> %tmp3
|
|
|
|
|
}
|
|
|
|
|
|