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/load-local-v3i1.ll

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

130 lines
4.6 KiB
LLVM
Raw Normal View History

[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[LegalizeVectorTypes] Allow single loads and stores for more short vectors When lowering a load or store for TypeWidenVector, the type legalizer would use a single load or store if the associated integer type was legal or promoted. E.g. it loads a v4i8 as an i32 if i32 is legal/promotable. (See https://reviews.llvm.org/rL236528 for reference.) This applies that behaviour to vector types. If the vector type is TypePromoteInteger, the element type is going to be TypePromoteInteger as well, which will lead to have a single promoting load rather than N individual promoting loads. For instance, if we have a v3i1, we would now have a load of v4i1 instead of 3 loads of i1. Patch by Guillaume Marques. Thanks! Differential Revision: https://reviews.llvm.org/D56201 llvm-svn: 357120
2019-03-28 04:35:56 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse4.2 | FileCheck %s
; widen a v3i1 to v4i1 to do a vector load/store. We would previously
; reconstruct the said v3i1 from the first element of the vector by filling all
; the lanes of the vector with that first element, which was obviously wrong.
; This was done in the type-legalizing of the DAG, when legalizing the load.
; Function Attrs: argmemonly nounwind readonly
declare <3 x i32> @llvm.masked.load.v3i32.p1v3i32(<3 x i32> addrspace(1)*, i32, <3 x i1>, <3 x i32>)
; Function Attrs: argmemonly nounwind
declare void @llvm.masked.store.v3i32.p1v3i32(<3 x i32>, <3 x i32> addrspace(1)*, i32, <3 x i1>)
define <3 x i32> @masked_load_v3(i32 addrspace(1)*, <3 x i1>) {
[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; CHECK-LABEL: masked_load_v3:
; CHECK: # %bb.0: # %entry
; CHECK-NEXT: andb $1, %sil
; CHECK-NEXT: andb $1, %dl
; CHECK-NEXT: addb %dl, %dl
; CHECK-NEXT: orb %sil, %dl
; CHECK-NEXT: andb $1, %cl
; CHECK-NEXT: shlb $2, %cl
; CHECK-NEXT: orb %dl, %cl
; CHECK-NEXT: testb $1, %cl
; CHECK-NEXT: # implicit-def: $xmm0
; CHECK-NEXT: jne .LBB0_1
; CHECK-NEXT: # %bb.2: # %else
; CHECK-NEXT: testb $2, %cl
; CHECK-NEXT: jne .LBB0_3
; CHECK-NEXT: .LBB0_4: # %else2
; CHECK-NEXT: testb $4, %cl
; CHECK-NEXT: jne .LBB0_5
; CHECK-NEXT: .LBB0_6: # %else5
; CHECK-NEXT: retq
; CHECK-NEXT: .LBB0_1: # %cond.load
; CHECK-NEXT: movd {{.*#+}} xmm0 = mem[0],zero,zero,zero
; CHECK-NEXT: testb $2, %cl
; CHECK-NEXT: je .LBB0_4
; CHECK-NEXT: .LBB0_3: # %cond.load1
; CHECK-NEXT: pinsrd $1, 4(%rdi), %xmm0
; CHECK-NEXT: testb $4, %cl
; CHECK-NEXT: je .LBB0_6
; CHECK-NEXT: .LBB0_5: # %cond.load4
; CHECK-NEXT: pinsrd $2, 8(%rdi), %xmm0
; CHECK-NEXT: retq
[LegalizeVectorTypes] Allow single loads and stores for more short vectors When lowering a load or store for TypeWidenVector, the type legalizer would use a single load or store if the associated integer type was legal or promoted. E.g. it loads a v4i8 as an i32 if i32 is legal/promotable. (See https://reviews.llvm.org/rL236528 for reference.) This applies that behaviour to vector types. If the vector type is TypePromoteInteger, the element type is going to be TypePromoteInteger as well, which will lead to have a single promoting load rather than N individual promoting loads. For instance, if we have a v3i1, we would now have a load of v4i1 instead of 3 loads of i1. Patch by Guillaume Marques. Thanks! Differential Revision: https://reviews.llvm.org/D56201 llvm-svn: 357120
2019-03-28 04:35:56 +08:00
entry:
%2 = bitcast i32 addrspace(1)* %0 to <3 x i32> addrspace(1)*
%3 = call <3 x i32> @llvm.masked.load.v3i32.p1v3i32(<3 x i32> addrspace(1)* %2, i32 4, <3 x i1> %1, <3 x i32> undef)
ret <3 x i32> %3
}
define void @masked_store4_v3(<3 x i32>, i32 addrspace(1)*, <3 x i1>) {
[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; CHECK-LABEL: masked_store4_v3:
; CHECK: # %bb.0: # %entry
; CHECK-NEXT: andb $1, %sil
; CHECK-NEXT: andb $1, %dl
; CHECK-NEXT: addb %dl, %dl
; CHECK-NEXT: orb %sil, %dl
; CHECK-NEXT: andb $1, %cl
; CHECK-NEXT: shlb $2, %cl
; CHECK-NEXT: orb %dl, %cl
; CHECK-NEXT: testb $1, %cl
; CHECK-NEXT: jne .LBB1_1
; CHECK-NEXT: # %bb.2: # %else
; CHECK-NEXT: testb $2, %cl
; CHECK-NEXT: jne .LBB1_3
; CHECK-NEXT: .LBB1_4: # %else2
; CHECK-NEXT: testb $4, %cl
; CHECK-NEXT: jne .LBB1_5
; CHECK-NEXT: .LBB1_6: # %else4
; CHECK-NEXT: retq
; CHECK-NEXT: .LBB1_1: # %cond.store
; CHECK-NEXT: movss %xmm0, (%rdi)
; CHECK-NEXT: testb $2, %cl
; CHECK-NEXT: je .LBB1_4
; CHECK-NEXT: .LBB1_3: # %cond.store1
; CHECK-NEXT: extractps $1, %xmm0, 4(%rdi)
; CHECK-NEXT: testb $4, %cl
; CHECK-NEXT: je .LBB1_6
; CHECK-NEXT: .LBB1_5: # %cond.store3
; CHECK-NEXT: extractps $2, %xmm0, 8(%rdi)
; CHECK-NEXT: retq
[LegalizeVectorTypes] Allow single loads and stores for more short vectors When lowering a load or store for TypeWidenVector, the type legalizer would use a single load or store if the associated integer type was legal or promoted. E.g. it loads a v4i8 as an i32 if i32 is legal/promotable. (See https://reviews.llvm.org/rL236528 for reference.) This applies that behaviour to vector types. If the vector type is TypePromoteInteger, the element type is going to be TypePromoteInteger as well, which will lead to have a single promoting load rather than N individual promoting loads. For instance, if we have a v3i1, we would now have a load of v4i1 instead of 3 loads of i1. Patch by Guillaume Marques. Thanks! Differential Revision: https://reviews.llvm.org/D56201 llvm-svn: 357120
2019-03-28 04:35:56 +08:00
entry:
%3 = bitcast i32 addrspace(1)* %1 to <3 x i32> addrspace(1)*
call void @llvm.masked.store.v3i32.p1v3i32(<3 x i32> %0, <3 x i32> addrspace(1)* %3, i32 4, <3 x i1> %2)
ret void
}
define void @local_load_v3i1(i32 addrspace(1)* %out, i32 addrspace(1)* %in, <3 x i1>* %predicate_ptr) nounwind {
; CHECK-LABEL: local_load_v3i1:
; CHECK: # %bb.0:
[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; CHECK-NEXT: pushq %rbp
; CHECK-NEXT: pushq %r15
; CHECK-NEXT: pushq %r14
; CHECK-NEXT: pushq %rbx
; CHECK-NEXT: pushq %rax
; CHECK-NEXT: movq %rdi, %r14
[LegalizeTypes] Scalarize non-byte sized loads in WidenRecRes_Load and SplitVecResLoad Should fix PR42803 and PR44902 Differential Revision: https://reviews.llvm.org/D74590
2020-02-25 06:08:05 +08:00
; CHECK-NEXT: movb (%rdx), %al
; CHECK-NEXT: movl %eax, %ecx
[SelectionDAG] Unify scalarizeVectorLoad and VectorLegalizer::ExpandLoad The two code paths have the same goal, legalizing a load of a non-byte-sized vector by loading the "flattened" representation in memory, slicing off each single element and then building a vector out of those pieces. The technique employed by `ExpandLoad` is slightly more convoluted and produces slightly better codegen on ARM, AMDGPU and x86 but suffers from some bugs (D78480) and is wrong for BE machines. Differential Revision: https://reviews.llvm.org/D79096
2020-05-03 05:09:18 +08:00
; CHECK-NEXT: shrb %cl
; CHECK-NEXT: andb $1, %cl
; CHECK-NEXT: movl %eax, %edx
; CHECK-NEXT: shrb $2, %dl
; CHECK-NEXT: andb $1, %al
; CHECK-NEXT: movzbl %al, %ebp
; CHECK-NEXT: movzbl %dl, %r15d
; CHECK-NEXT: movzbl %cl, %ebx
[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; CHECK-NEXT: movq %rsi, %rdi
[SelectionDAG] Unify scalarizeVectorLoad and VectorLegalizer::ExpandLoad The two code paths have the same goal, legalizing a load of a non-byte-sized vector by loading the "flattened" representation in memory, slicing off each single element and then building a vector out of those pieces. The technique employed by `ExpandLoad` is slightly more convoluted and produces slightly better codegen on ARM, AMDGPU and x86 but suffers from some bugs (D78480) and is wrong for BE machines. Differential Revision: https://reviews.llvm.org/D79096
2020-05-03 05:09:18 +08:00
; CHECK-NEXT: movl %ebp, %esi
[LegalizeTypes] Scalarize non-byte sized loads in WidenRecRes_Load and SplitVecResLoad Should fix PR42803 and PR44902 Differential Revision: https://reviews.llvm.org/D74590
2020-02-25 06:08:05 +08:00
; CHECK-NEXT: movl %ebx, %edx
[SelectionDAG] Unify scalarizeVectorLoad and VectorLegalizer::ExpandLoad The two code paths have the same goal, legalizing a load of a non-byte-sized vector by loading the "flattened" representation in memory, slicing off each single element and then building a vector out of those pieces. The technique employed by `ExpandLoad` is slightly more convoluted and produces slightly better codegen on ARM, AMDGPU and x86 but suffers from some bugs (D78480) and is wrong for BE machines. Differential Revision: https://reviews.llvm.org/D79096
2020-05-03 05:09:18 +08:00
; CHECK-NEXT: movl %r15d, %ecx
[NFC][X86][Codegen] Megacommit: mass-regenerate all check lines that were already autogenerated The motivation is that the update script has at least two deviations (`<...>@GOT`/`<...>@PLT`/ and not hiding pointer arithmetics) from what pretty much all the checklines were generated with, and most of the tests are still not updated, so each time one of the non-up-to-date tests is updated to see the effect of the code change, there is a lot of noise. Instead of having to deal with that each time, let's just deal with everything at once. This has been done via: ``` cd llvm-project/llvm/test/CodeGen/X86 grep -rl "; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py" | xargs -L1 <...>/llvm-project/llvm/utils/update_llc_test_checks.py --llc-binary <...>/llvm-project/build/bin/llc ``` Not all tests were regenerated, however.
2021-06-12 04:26:17 +08:00
; CHECK-NEXT: callq masked_load_v3@PLT
[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; CHECK-NEXT: movq %r14, %rdi
[SelectionDAG] Unify scalarizeVectorLoad and VectorLegalizer::ExpandLoad The two code paths have the same goal, legalizing a load of a non-byte-sized vector by loading the "flattened" representation in memory, slicing off each single element and then building a vector out of those pieces. The technique employed by `ExpandLoad` is slightly more convoluted and produces slightly better codegen on ARM, AMDGPU and x86 but suffers from some bugs (D78480) and is wrong for BE machines. Differential Revision: https://reviews.llvm.org/D79096
2020-05-03 05:09:18 +08:00
; CHECK-NEXT: movl %ebp, %esi
[LegalizeTypes] Scalarize non-byte sized loads in WidenRecRes_Load and SplitVecResLoad Should fix PR42803 and PR44902 Differential Revision: https://reviews.llvm.org/D74590
2020-02-25 06:08:05 +08:00
; CHECK-NEXT: movl %ebx, %edx
[SelectionDAG] Unify scalarizeVectorLoad and VectorLegalizer::ExpandLoad The two code paths have the same goal, legalizing a load of a non-byte-sized vector by loading the "flattened" representation in memory, slicing off each single element and then building a vector out of those pieces. The technique employed by `ExpandLoad` is slightly more convoluted and produces slightly better codegen on ARM, AMDGPU and x86 but suffers from some bugs (D78480) and is wrong for BE machines. Differential Revision: https://reviews.llvm.org/D79096
2020-05-03 05:09:18 +08:00
; CHECK-NEXT: movl %r15d, %ecx
[NFC][X86][Codegen] Megacommit: mass-regenerate all check lines that were already autogenerated The motivation is that the update script has at least two deviations (`<...>@GOT`/`<...>@PLT`/ and not hiding pointer arithmetics) from what pretty much all the checklines were generated with, and most of the tests are still not updated, so each time one of the non-up-to-date tests is updated to see the effect of the code change, there is a lot of noise. Instead of having to deal with that each time, let's just deal with everything at once. This has been done via: ``` cd llvm-project/llvm/test/CodeGen/X86 grep -rl "; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py" | xargs -L1 <...>/llvm-project/llvm/utils/update_llc_test_checks.py --llc-binary <...>/llvm-project/build/bin/llc ``` Not all tests were regenerated, however.
2021-06-12 04:26:17 +08:00
; CHECK-NEXT: callq masked_store4_v3@PLT
[X86] Automatically generate load-local-v3i1.ll . NFC llvm-svn: 369793
2019-08-24 02:12:33 +08:00
; CHECK-NEXT: addq $8, %rsp
; CHECK-NEXT: popq %rbx
; CHECK-NEXT: popq %r14
; CHECK-NEXT: popq %r15
; CHECK-NEXT: popq %rbp
; CHECK-NEXT: retq
[LegalizeVectorTypes] Allow single loads and stores for more short vectors When lowering a load or store for TypeWidenVector, the type legalizer would use a single load or store if the associated integer type was legal or promoted. E.g. it loads a v4i8 as an i32 if i32 is legal/promotable. (See https://reviews.llvm.org/rL236528 for reference.) This applies that behaviour to vector types. If the vector type is TypePromoteInteger, the element type is going to be TypePromoteInteger as well, which will lead to have a single promoting load rather than N individual promoting loads. For instance, if we have a v3i1, we would now have a load of v4i1 instead of 3 loads of i1. Patch by Guillaume Marques. Thanks! Differential Revision: https://reviews.llvm.org/D56201 llvm-svn: 357120
2019-03-28 04:35:56 +08:00
%predicate = load <3 x i1>, <3 x i1>* %predicate_ptr
%load1 = call <3 x i32> @masked_load_v3(i32 addrspace(1)* %in, <3 x i1> %predicate)
call void @masked_store4_v3(<3 x i32> %load1, i32 addrspace(1)* %out, <3 x i1> %predicate)
ret void
}