maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Verifier/get-active-lane-mask.ll

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

22 lines
717 B
LLVM
Raw Normal View History

New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
; RUN: not llvm-as < %s -o /dev/null 2>&1 | FileCheck %s
Revert "[Verifier] Additional check for intrinsic get.active.lane.mask" This reverts commit 8d5f64c4edbc190a5a8790157fa1d99cfac34016. Thanks to Eli Friedma for pointing out that this check is not appropiate here, this check will be moved to the Lint pass.
2020-08-27 15:59:27 +08:00
declare <4 x i32> @llvm.get.active.lane.mask.v4i32.i32(i32, i32)
New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
[ARM] Fixup of a few test cases. NFC. After changing the semantics of get.active.lane.mask, I missed a few tests that should use now the tripcount instead of the backedge taken count.
2020-09-09 17:40:23 +08:00
define <4 x i32> @t1(i32 %IV, i32 %TC) {
New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
; CHECK: get_active_lane_mask: element type is not i1
[ARM] Fixup of a few test cases. NFC. After changing the semantics of get.active.lane.mask, I missed a few tests that should use now the tripcount instead of the backedge taken count.
2020-09-09 17:40:23 +08:00
; CHECK-NEXT: %res = call <4 x i32> @llvm.get.active.lane.mask.v4i32.i32(i32 %IV, i32 %TC)
New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
[ARM] Fixup of a few test cases. NFC. After changing the semantics of get.active.lane.mask, I missed a few tests that should use now the tripcount instead of the backedge taken count.
2020-09-09 17:40:23 +08:00
%res = call <4 x i32> @llvm.get.active.lane.mask.v4i32.i32(i32 %IV, i32 %TC)
New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
ret <4 x i32> %res
}
Revert "[Verifier] Additional check for intrinsic get.active.lane.mask" This reverts commit 8d5f64c4edbc190a5a8790157fa1d99cfac34016. Thanks to Eli Friedma for pointing out that this check is not appropiate here, this check will be moved to the Lint pass.
2020-08-27 15:59:27 +08:00
declare i32 @llvm.get.active.lane.mask.i32.i32(i32, i32)
[ARM] Fixup of a few test cases. NFC. After changing the semantics of get.active.lane.mask, I missed a few tests that should use now the tripcount instead of the backedge taken count.
2020-09-09 17:40:23 +08:00
define i32 @t2(i32 %IV, i32 %TC) {
New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
; CHECK: Intrinsic has incorrect return type!
; CHECK-NEXT: i32 (i32, i32)* @llvm.get.active.lane.mask.i32.i32
[ARM] Fixup of a few test cases. NFC. After changing the semantics of get.active.lane.mask, I missed a few tests that should use now the tripcount instead of the backedge taken count.
2020-09-09 17:40:23 +08:00
%res = call i32 @llvm.get.active.lane.mask.i32.i32(i32 %IV, i32 %TC)
New intrinsic @llvm.get.active.lane.mask() This is split off from D79100 and: - adds a intrinsic description/definition for @llvm.get.active.lane.mask(), and - describe its semantics in LangRef. As described (in more detail) in its LangRef section, it is semantically equivalent to an icmp with the vector induction variable and the back-edge taken count, and generates a mask of active/inactive vector lanes. It will have several use cases. First, it will be used by the ExpandVectorPredication pass for the VP intrinsics, to expand VP intrinsics for scalable vectors on targets that do not support the `%evl` parameter, see D78203. Also, this is part of, and essential for our ARM MVE tail-predication story: - this intrinsic will be emitted by the LoopVectorizer in D79100, when the scalar epilogue is tail-folded into the vector body. This new intrinsic will generate the predicate for the masked loads/stores, and it takes the back-edge taken count as an argument. The back-edge taken count represents the number of elements processed by the loop, which we need to setup MVE tail-predication. - Emitting the intrinsic is controlled by a new TTI hook, see D80597. - We pick up this new intrinsic in an ARM MVETailPredication backend pass, see D79175, and convert it to a MVE target specific intrinsic/instruction to create a tail-predicated loop. Differential Revision: https://reviews.llvm.org/D80596
2020-05-29 15:27:22 +08:00
ret i32 %res
}