2017-06-19 05:42:19 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
|
; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+sse4.2 | FileCheck %s --check-prefix=NARROW
|
|
|
|
|
; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+sse4.2 -x86-experimental-vector-widening-legalization | FileCheck %s --check-prefix=WIDE
|
|
|
|
|
|
|
|
|
|
; FIXME: We shouldn't require both a movd and an insert in the wide version.
|
2008-12-19 04:05:58 +08:00
|
|
|
|
|
|
|
|
define void @update(i64* %dst_i, i64* %src_i, i32 %n) nounwind {
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-LABEL: update:
|
2017-12-05 01:18:51 +08:00
|
|
|
; NARROW: # %bb.0: # %entry
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: subl $12, %esp
|
|
|
|
|
; NARROW-NEXT: movl $0, (%esp)
|
[x86] transform vector inc/dec to use -1 constant (PR33483)
Convert vector increment or decrement to sub/add with an all-ones constant:
add X, <1, 1...> --> sub X, <-1, -1...>
sub X, <1, 1...> --> add X, <-1, -1...>
The all-ones vector constant can be materialized using a pcmpeq instruction that is
commonly recognized as an idiom (has no register dependency), so that's better than
loading a splat 1 constant.
AVX512 uses 'vpternlogd' for 512-bit vectors because there is apparently no better
way to produce 512 one-bits.
The general advantages of this lowering are:
1. pcmpeq has lower latency than a memop on every uarch I looked at in Agner's tables,
so in theory, this could be better for perf, but...
2. That seems unlikely to affect any OOO implementation, and I can't measure any real
perf difference from this transform on Haswell or Jaguar, but...
3. It doesn't look like it from the diffs, but this is an overall size win because we
eliminate 16 - 64 constant bytes in the case of a vector load. If we're broadcasting
a scalar load (which might itself be a bug), then we're replacing a scalar constant
load + broadcast with a single cheap op, so that should always be smaller/better too.
4. This makes the DAG/isel output more consistent - we use pcmpeq already for padd x, -1
and psub x, -1, so we should use that form for +1 too because we can. If there's some
reason to favor a constant load on some CPU, let's make the reverse transform for all
of these cases (either here in the DAG or in a later machine pass).
This should fix:
https://bugs.llvm.org/show_bug.cgi?id=33483
Differential Revision: https://reviews.llvm.org/D34336
llvm-svn: 306289
2017-06-26 22:19:26 +08:00
|
|
|
; NARROW-NEXT: pcmpeqd %xmm0, %xmm0
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: movdqa {{.*#+}} xmm1 = <0,2,4,6,8,10,12,14,u,u,u,u,u,u,u,u>
|
|
|
|
|
; NARROW-NEXT: jmp .LBB0_1
|
|
|
|
|
; NARROW-NEXT: .p2align 4, 0x90
|
|
|
|
|
; NARROW-NEXT: .LBB0_2: # %forbody
|
|
|
|
|
; NARROW-NEXT: # in Loop: Header=BB0_1 Depth=1
|
|
|
|
|
; NARROW-NEXT: movl (%esp), %eax
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; NARROW-NEXT: leal (,%eax,8), %ecx
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: movl {{[0-9]+}}(%esp), %edx
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; NARROW-NEXT: addl %ecx, %edx
|
|
|
|
|
; NARROW-NEXT: movl %edx, {{[0-9]+}}(%esp)
|
|
|
|
|
; NARROW-NEXT: addl {{[0-9]+}}(%esp), %ecx
|
|
|
|
|
; NARROW-NEXT: movl %ecx, {{[0-9]+}}(%esp)
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: pmovzxbw {{.*#+}} xmm2 = mem[0],zero,mem[1],zero,mem[2],zero,mem[3],zero,mem[4],zero,mem[5],zero,mem[6],zero,mem[7],zero
|
[x86] transform vector inc/dec to use -1 constant (PR33483)
Convert vector increment or decrement to sub/add with an all-ones constant:
add X, <1, 1...> --> sub X, <-1, -1...>
sub X, <1, 1...> --> add X, <-1, -1...>
The all-ones vector constant can be materialized using a pcmpeq instruction that is
commonly recognized as an idiom (has no register dependency), so that's better than
loading a splat 1 constant.
AVX512 uses 'vpternlogd' for 512-bit vectors because there is apparently no better
way to produce 512 one-bits.
The general advantages of this lowering are:
1. pcmpeq has lower latency than a memop on every uarch I looked at in Agner's tables,
so in theory, this could be better for perf, but...
2. That seems unlikely to affect any OOO implementation, and I can't measure any real
perf difference from this transform on Haswell or Jaguar, but...
3. It doesn't look like it from the diffs, but this is an overall size win because we
eliminate 16 - 64 constant bytes in the case of a vector load. If we're broadcasting
a scalar load (which might itself be a bug), then we're replacing a scalar constant
load + broadcast with a single cheap op, so that should always be smaller/better too.
4. This makes the DAG/isel output more consistent - we use pcmpeq already for padd x, -1
and psub x, -1, so we should use that form for +1 too because we can. If there's some
reason to favor a constant load on some CPU, let's make the reverse transform for all
of these cases (either here in the DAG or in a later machine pass).
This should fix:
https://bugs.llvm.org/show_bug.cgi?id=33483
Differential Revision: https://reviews.llvm.org/D34336
llvm-svn: 306289
2017-06-26 22:19:26 +08:00
|
|
|
; NARROW-NEXT: psubw %xmm0, %xmm2
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: psllw $8, %xmm2
|
|
|
|
|
; NARROW-NEXT: psraw $8, %xmm2
|
2017-09-26 03:26:08 +08:00
|
|
|
; NARROW-NEXT: psrlw $2, %xmm2
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: pshufb %xmm1, %xmm2
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; NARROW-NEXT: movq %xmm2, (%edx,%eax,8)
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: incl (%esp)
|
|
|
|
|
; NARROW-NEXT: .LBB0_1: # %forcond
|
|
|
|
|
; NARROW-NEXT: # =>This Inner Loop Header: Depth=1
|
|
|
|
|
; NARROW-NEXT: movl (%esp), %eax
|
|
|
|
|
; NARROW-NEXT: cmpl {{[0-9]+}}(%esp), %eax
|
|
|
|
|
; NARROW-NEXT: jl .LBB0_2
|
2017-12-05 01:18:51 +08:00
|
|
|
; NARROW-NEXT: # %bb.3: # %afterfor
|
2017-06-19 05:42:19 +08:00
|
|
|
; NARROW-NEXT: addl $12, %esp
|
|
|
|
|
; NARROW-NEXT: retl
|
|
|
|
|
;
|
|
|
|
|
; WIDE-LABEL: update:
|
2017-12-05 01:18:51 +08:00
|
|
|
; WIDE: # %bb.0: # %entry
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: subl $12, %esp
|
|
|
|
|
; WIDE-NEXT: movl $0, (%esp)
|
[x86] transform vector inc/dec to use -1 constant (PR33483)
Convert vector increment or decrement to sub/add with an all-ones constant:
add X, <1, 1...> --> sub X, <-1, -1...>
sub X, <1, 1...> --> add X, <-1, -1...>
The all-ones vector constant can be materialized using a pcmpeq instruction that is
commonly recognized as an idiom (has no register dependency), so that's better than
loading a splat 1 constant.
AVX512 uses 'vpternlogd' for 512-bit vectors because there is apparently no better
way to produce 512 one-bits.
The general advantages of this lowering are:
1. pcmpeq has lower latency than a memop on every uarch I looked at in Agner's tables,
so in theory, this could be better for perf, but...
2. That seems unlikely to affect any OOO implementation, and I can't measure any real
perf difference from this transform on Haswell or Jaguar, but...
3. It doesn't look like it from the diffs, but this is an overall size win because we
eliminate 16 - 64 constant bytes in the case of a vector load. If we're broadcasting
a scalar load (which might itself be a bug), then we're replacing a scalar constant
load + broadcast with a single cheap op, so that should always be smaller/better too.
4. This makes the DAG/isel output more consistent - we use pcmpeq already for padd x, -1
and psub x, -1, so we should use that form for +1 too because we can. If there's some
reason to favor a constant load on some CPU, let's make the reverse transform for all
of these cases (either here in the DAG or in a later machine pass).
This should fix:
https://bugs.llvm.org/show_bug.cgi?id=33483
Differential Revision: https://reviews.llvm.org/D34336
llvm-svn: 306289
2017-06-26 22:19:26 +08:00
|
|
|
; WIDE-NEXT: pcmpeqd %xmm0, %xmm0
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: movdqa {{.*#+}} xmm1 = [63,63,63,63,63,63,63,63,63,63,63,63,63,63,63,63]
|
|
|
|
|
; WIDE-NEXT: movdqa {{.*#+}} xmm2 = [32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32]
|
|
|
|
|
; WIDE-NEXT: jmp .LBB0_1
|
|
|
|
|
; WIDE-NEXT: .p2align 4, 0x90
|
|
|
|
|
; WIDE-NEXT: .LBB0_2: # %forbody
|
|
|
|
|
; WIDE-NEXT: # in Loop: Header=BB0_1 Depth=1
|
|
|
|
|
; WIDE-NEXT: movl (%esp), %eax
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; WIDE-NEXT: leal (,%eax,8), %ecx
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: movl {{[0-9]+}}(%esp), %edx
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; WIDE-NEXT: addl %ecx, %edx
|
|
|
|
|
; WIDE-NEXT: movl %edx, {{[0-9]+}}(%esp)
|
|
|
|
|
; WIDE-NEXT: addl {{[0-9]+}}(%esp), %ecx
|
|
|
|
|
; WIDE-NEXT: movl %ecx, {{[0-9]+}}(%esp)
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: movd {{.*#+}} xmm3 = mem[0],zero,zero,zero
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; WIDE-NEXT: pinsrd $1, 4(%ecx,%eax,8), %xmm3
|
[x86] transform vector inc/dec to use -1 constant (PR33483)
Convert vector increment or decrement to sub/add with an all-ones constant:
add X, <1, 1...> --> sub X, <-1, -1...>
sub X, <1, 1...> --> add X, <-1, -1...>
The all-ones vector constant can be materialized using a pcmpeq instruction that is
commonly recognized as an idiom (has no register dependency), so that's better than
loading a splat 1 constant.
AVX512 uses 'vpternlogd' for 512-bit vectors because there is apparently no better
way to produce 512 one-bits.
The general advantages of this lowering are:
1. pcmpeq has lower latency than a memop on every uarch I looked at in Agner's tables,
so in theory, this could be better for perf, but...
2. That seems unlikely to affect any OOO implementation, and I can't measure any real
perf difference from this transform on Haswell or Jaguar, but...
3. It doesn't look like it from the diffs, but this is an overall size win because we
eliminate 16 - 64 constant bytes in the case of a vector load. If we're broadcasting
a scalar load (which might itself be a bug), then we're replacing a scalar constant
load + broadcast with a single cheap op, so that should always be smaller/better too.
4. This makes the DAG/isel output more consistent - we use pcmpeq already for padd x, -1
and psub x, -1, so we should use that form for +1 too because we can. If there's some
reason to favor a constant load on some CPU, let's make the reverse transform for all
of these cases (either here in the DAG or in a later machine pass).
This should fix:
https://bugs.llvm.org/show_bug.cgi?id=33483
Differential Revision: https://reviews.llvm.org/D34336
llvm-svn: 306289
2017-06-26 22:19:26 +08:00
|
|
|
; WIDE-NEXT: psubb %xmm0, %xmm3
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: psrlw $2, %xmm3
|
|
|
|
|
; WIDE-NEXT: pand %xmm1, %xmm3
|
|
|
|
|
; WIDE-NEXT: pxor %xmm2, %xmm3
|
|
|
|
|
; WIDE-NEXT: psubb %xmm2, %xmm3
|
[DAG] Improve Aliasing of operations to static alloca
Re-recommiting after landing DAG extension-crash fix.
Recommiting after adding check to avoid miscomputing alias information
on addresses of the same base but different subindices.
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
llvm-svn: 308350
2017-07-19 04:06:24 +08:00
|
|
|
; WIDE-NEXT: pextrd $1, %xmm3, 4(%edx,%eax,8)
|
|
|
|
|
; WIDE-NEXT: movd %xmm3, (%edx,%eax,8)
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: incl (%esp)
|
|
|
|
|
; WIDE-NEXT: .LBB0_1: # %forcond
|
|
|
|
|
; WIDE-NEXT: # =>This Inner Loop Header: Depth=1
|
|
|
|
|
; WIDE-NEXT: movl (%esp), %eax
|
|
|
|
|
; WIDE-NEXT: cmpl {{[0-9]+}}(%esp), %eax
|
|
|
|
|
; WIDE-NEXT: jl .LBB0_2
|
2017-12-05 01:18:51 +08:00
|
|
|
; WIDE-NEXT: # %bb.3: # %afterfor
|
2017-06-19 05:42:19 +08:00
|
|
|
; WIDE-NEXT: addl $12, %esp
|
|
|
|
|
; WIDE-NEXT: retl
|
2008-12-19 04:05:58 +08:00
|
|
|
entry:
|
2017-06-19 05:42:19 +08:00
|
|
|
%dst_i.addr = alloca i64*
|
|
|
|
|
%src_i.addr = alloca i64*
|
|
|
|
|
%n.addr = alloca i32
|
|
|
|
|
%i = alloca i32, align 4
|
|
|
|
|
%dst = alloca <8 x i8>*, align 4
|
|
|
|
|
%src = alloca <8 x i8>*, align 4
|
2008-12-19 04:05:58 +08:00
|
|
|
store i64* %dst_i, i64** %dst_i.addr
|
|
|
|
|
store i64* %src_i, i64** %src_i.addr
|
|
|
|
|
store i32 %n, i32* %n.addr
|
|
|
|
|
store i32 0, i32* %i
|
|
|
|
|
br label %forcond
|
|
|
|
|
|
2017-06-19 05:42:19 +08:00
|
|
|
forcond:
|
|
|
|
|
%tmp = load i32, i32* %i
|
|
|
|
|
%tmp1 = load i32, i32* %n.addr
|
|
|
|
|
%cmp = icmp slt i32 %tmp, %tmp1
|
2008-12-19 04:05:58 +08:00
|
|
|
br i1 %cmp, label %forbody, label %afterfor
|
|
|
|
|
|
2017-06-19 05:42:19 +08:00
|
|
|
forbody:
|
|
|
|
|
%tmp2 = load i32, i32* %i
|
|
|
|
|
%tmp3 = load i64*, i64** %dst_i.addr
|
|
|
|
|
%arrayidx = getelementptr i64, i64* %tmp3, i32 %tmp2
|
|
|
|
|
%conv = bitcast i64* %arrayidx to <8 x i8>*
|
2008-12-19 04:05:58 +08:00
|
|
|
store <8 x i8>* %conv, <8 x i8>** %dst
|
2017-06-19 05:42:19 +08:00
|
|
|
%tmp4 = load i32, i32* %i
|
|
|
|
|
%tmp5 = load i64*, i64** %src_i.addr
|
|
|
|
|
%arrayidx6 = getelementptr i64, i64* %tmp5, i32 %tmp4
|
|
|
|
|
%conv7 = bitcast i64* %arrayidx6 to <8 x i8>*
|
2008-12-19 04:05:58 +08:00
|
|
|
store <8 x i8>* %conv7, <8 x i8>** %src
|
2017-06-19 05:42:19 +08:00
|
|
|
%tmp8 = load i32, i32* %i
|
|
|
|
|
%tmp9 = load <8 x i8>*, <8 x i8>** %dst
|
|
|
|
|
%arrayidx10 = getelementptr <8 x i8>, <8 x i8>* %tmp9, i32 %tmp8
|
|
|
|
|
%tmp11 = load i32, i32* %i
|
|
|
|
|
%tmp12 = load <8 x i8>*, <8 x i8>** %src
|
|
|
|
|
%arrayidx13 = getelementptr <8 x i8>, <8 x i8>* %tmp12, i32 %tmp11
|
|
|
|
|
%tmp14 = load <8 x i8>, <8 x i8>* %arrayidx13
|
|
|
|
|
%add = add <8 x i8> %tmp14, < i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1, i8 1 >
|
|
|
|
|
%shr = ashr <8 x i8> %add, < i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2 >
|
2008-12-19 04:05:58 +08:00
|
|
|
store <8 x i8> %shr, <8 x i8>* %arrayidx10
|
|
|
|
|
br label %forinc
|
|
|
|
|
|
2017-06-19 05:42:19 +08:00
|
|
|
forinc:
|
|
|
|
|
%tmp15 = load i32, i32* %i
|
|
|
|
|
%inc = add i32 %tmp15, 1
|
2008-12-19 04:05:58 +08:00
|
|
|
store i32 %inc, i32* %i
|
|
|
|
|
br label %forcond
|
|
|
|
|
|
2017-06-19 05:42:19 +08:00
|
|
|
afterfor:
|
2008-12-19 04:05:58 +08:00
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|