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/widen_cast-4.ll

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

93 lines
3.1 KiB
LLVM
Raw Normal View History

[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
Recommit r368079 "[X86] Remove uses of the -x86-experimental-vector-widening-legalization flag from test/CodeGen/X86/" llvm-svn: 368184
2019-08-08 00:33:37 +08:00
; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+sse4.2 | FileCheck %s --check-prefix=WIDE
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
; FIXME: We shouldn't require both a movd and an insert in the wide version.
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
define void @update(i64* %dst_i, i64* %src_i, i32 %n) nounwind {
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
; WIDE-LABEL: update:
[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
; WIDE: # %bb.0: # %entry
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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: .p2align 4, 0x90
Revert [MBP] Disable aggressive loop rotate in plain mode This reverts r369664 (git commit 51f48295cbe8fa3a44db263b528dd9f7bae7bf9a) It causes many benchmark regressions, internally and in llvm's benchmark suite. llvm-svn: 370398
2019-08-30 03:03:58 +08:00
; 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: jge .LBB0_3
; WIDE-NEXT: # %bb.2: # %forbody
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
; 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
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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)
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; WIDE-NEXT: movq {{.*#+}} xmm3 = mem[0],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
; WIDE-NEXT: psubb %xmm0, %xmm3
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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
[X86] Support v2i32/v4i16/v8i8 load/store using f64 on 32-bit targets under -x86-experimental-vector-widening-legalization. On 64-bit targets the type legalizer will use i64 to legalize these. But when i64 isn't legal, the type legalizer won't try an FP type. So do it manually instead. There are a few regressions in here due to some v2i32 operations like mul and div now being reassembled into a full vector just to store instead of storing the pieces. But this was already occuring in 64-bit mode so its not a new issue. llvm-svn: 346908
2018-11-15 07:02:09 +08:00
; WIDE-NEXT: movq %xmm3, (%edx,%eax,8)
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
; WIDE-NEXT: incl (%esp)
Revert [MBP] Disable aggressive loop rotate in plain mode This reverts r369664 (git commit 51f48295cbe8fa3a44db263b528dd9f7bae7bf9a) It causes many benchmark regressions, internally and in llvm's benchmark suite. llvm-svn: 370398
2019-08-30 03:03:58 +08:00
; WIDE-NEXT: jmp .LBB0_1
; WIDE-NEXT: .LBB0_3: # %afterfor
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
; WIDE-NEXT: addl $12, %esp
; WIDE-NEXT: retl
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
entry:
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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
Added some basic test cases for r61209 llvm-svn: 61210
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
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
br i1 %cmp, label %forbody, label %afterfor
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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>*
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
store <8 x i8>* %conv, <8 x i8>** %dst
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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>*
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
store <8 x i8>* %conv7, <8 x i8>** %src
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
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 >
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
store <8 x i8> %shr, <8 x i8>* %arrayidx10
br label %forinc
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
forinc:
%tmp15 = load i32, i32* %i
%inc = add i32 %tmp15, 1
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
store i32 %inc, i32* %i
br label %forcond
[x86] specify triples and auto-generate complete checks; NFC llvm-svn: 305655
2017-06-19 05:42:19 +08:00
afterfor:
Added some basic test cases for r61209 llvm-svn: 61210
2008-12-19 04:05:58 +08:00
ret void
}