2019-09-09 20:54:47 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
; RUN: llc -mtriple=thumbv8.1m.main-none-eabi -mattr=+mve --verify-machineinstrs %s -o - | FileCheck %s
|
|
|
|
|
|
|
|
define void @vctp8(i32 %arg, <16 x i8> *%in, <16 x i8>* %out) {
|
|
|
|
; CHECK-LABEL: vctp8:
|
|
|
|
; CHECK: @ %bb.0:
|
|
|
|
; CHECK-NEXT: vmov.i32 q0, #0x0
|
2020-08-04 05:03:14 +08:00
|
|
|
; CHECK-NEXT: vctp.8 r0
|
|
|
|
; CHECK-NEXT: vldrw.u32 q1, [r1]
|
|
|
|
; CHECK-NEXT: vpst
|
|
|
|
; CHECK-NEXT: vmovt q0, q1
|
2019-09-09 20:54:47 +08:00
|
|
|
; CHECK-NEXT: vstrw.32 q0, [r2]
|
|
|
|
; CHECK-NEXT: bx lr
|
[ARM,MVE] Rename and clean up VCTP IR intrinsics.
Summary:
D65884 added a set of Arm IR intrinsics for the MVE VCTP instruction,
to use in tail predication. But the 64-bit one doesn't work properly:
its predicate type is `<2 x i1>` / `v2i1`, which isn't a legal MVE
type (due to not having a full set of instructions that manipulate it
usefully). The test of `vctp64` in `basic-tail-pred.ll` goes through
`opt` fine, as the test expects, but if you then feed it to `llc` it
causes a type legality failure at isel time.
The usual workaround we've been using in the rest of the MVE
intrinsics family is to bodge `v2i1` into `v4i1`. So I've adjusted the
`vctp64` IR intrinsic to do that, and completely removed the code (and
test) that uses that intrinsic for 64-bit tail predication. That will
allow me to add isel rules (upcoming in D70485) that actually generate
the VCTP64 instruction.
Also renamed all four of these IR intrinsics so that they have `mve`
in the name, since its absence was confusing.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Reviewed By: MarkMurrayARM
Subscribers: samparker, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70592
2019-12-03 00:18:24 +08:00
|
|
|
%pred = call <16 x i1> @llvm.arm.mve.vctp8(i32 %arg)
|
2019-09-09 20:54:47 +08:00
|
|
|
%ld = load <16 x i8>, <16 x i8>* %in
|
|
|
|
%res = select <16 x i1> %pred, <16 x i8> %ld, <16 x i8> zeroinitializer
|
|
|
|
store <16 x i8> %res, <16 x i8>* %out
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
define void @vctp16(i32 %arg, <8 x i16> *%in, <8 x i16>* %out) {
|
|
|
|
; CHECK-LABEL: vctp16:
|
|
|
|
; CHECK: @ %bb.0:
|
|
|
|
; CHECK-NEXT: vmov.i32 q0, #0x0
|
2020-08-04 05:03:14 +08:00
|
|
|
; CHECK-NEXT: vctp.16 r0
|
|
|
|
; CHECK-NEXT: vldrw.u32 q1, [r1]
|
|
|
|
; CHECK-NEXT: vpst
|
|
|
|
; CHECK-NEXT: vmovt q0, q1
|
2019-09-09 20:54:47 +08:00
|
|
|
; CHECK-NEXT: vstrw.32 q0, [r2]
|
|
|
|
; CHECK-NEXT: bx lr
|
[ARM,MVE] Rename and clean up VCTP IR intrinsics.
Summary:
D65884 added a set of Arm IR intrinsics for the MVE VCTP instruction,
to use in tail predication. But the 64-bit one doesn't work properly:
its predicate type is `<2 x i1>` / `v2i1`, which isn't a legal MVE
type (due to not having a full set of instructions that manipulate it
usefully). The test of `vctp64` in `basic-tail-pred.ll` goes through
`opt` fine, as the test expects, but if you then feed it to `llc` it
causes a type legality failure at isel time.
The usual workaround we've been using in the rest of the MVE
intrinsics family is to bodge `v2i1` into `v4i1`. So I've adjusted the
`vctp64` IR intrinsic to do that, and completely removed the code (and
test) that uses that intrinsic for 64-bit tail predication. That will
allow me to add isel rules (upcoming in D70485) that actually generate
the VCTP64 instruction.
Also renamed all four of these IR intrinsics so that they have `mve`
in the name, since its absence was confusing.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Reviewed By: MarkMurrayARM
Subscribers: samparker, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70592
2019-12-03 00:18:24 +08:00
|
|
|
%pred = call <8 x i1> @llvm.arm.mve.vctp16(i32 %arg)
|
2019-09-09 20:54:47 +08:00
|
|
|
%ld = load <8 x i16>, <8 x i16>* %in
|
|
|
|
%res = select <8 x i1> %pred, <8 x i16> %ld, <8 x i16> zeroinitializer
|
|
|
|
store <8 x i16> %res, <8 x i16>* %out
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
define void @vctp32(i32 %arg, <4 x i32> *%in, <4 x i32>* %out) {
|
|
|
|
; CHECK-LABEL: vctp32:
|
|
|
|
; CHECK: @ %bb.0:
|
|
|
|
; CHECK-NEXT: vmov.i32 q0, #0x0
|
2020-08-04 05:03:14 +08:00
|
|
|
; CHECK-NEXT: vctp.32 r0
|
|
|
|
; CHECK-NEXT: vldrw.u32 q1, [r1]
|
|
|
|
; CHECK-NEXT: vpst
|
|
|
|
; CHECK-NEXT: vmovt q0, q1
|
2019-09-09 20:54:47 +08:00
|
|
|
; CHECK-NEXT: vstrw.32 q0, [r2]
|
|
|
|
; CHECK-NEXT: bx lr
|
[ARM,MVE] Rename and clean up VCTP IR intrinsics.
Summary:
D65884 added a set of Arm IR intrinsics for the MVE VCTP instruction,
to use in tail predication. But the 64-bit one doesn't work properly:
its predicate type is `<2 x i1>` / `v2i1`, which isn't a legal MVE
type (due to not having a full set of instructions that manipulate it
usefully). The test of `vctp64` in `basic-tail-pred.ll` goes through
`opt` fine, as the test expects, but if you then feed it to `llc` it
causes a type legality failure at isel time.
The usual workaround we've been using in the rest of the MVE
intrinsics family is to bodge `v2i1` into `v4i1`. So I've adjusted the
`vctp64` IR intrinsic to do that, and completely removed the code (and
test) that uses that intrinsic for 64-bit tail predication. That will
allow me to add isel rules (upcoming in D70485) that actually generate
the VCTP64 instruction.
Also renamed all four of these IR intrinsics so that they have `mve`
in the name, since its absence was confusing.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Reviewed By: MarkMurrayARM
Subscribers: samparker, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70592
2019-12-03 00:18:24 +08:00
|
|
|
%pred = call <4 x i1> @llvm.arm.mve.vctp32(i32 %arg)
|
2019-09-09 20:54:47 +08:00
|
|
|
%ld = load <4 x i32>, <4 x i32>* %in
|
|
|
|
%res = select <4 x i1> %pred, <4 x i32> %ld, <4 x i32> zeroinitializer
|
|
|
|
store <4 x i32> %res, <4 x i32>* %out
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
[ARM,MVE] Rename and clean up VCTP IR intrinsics.
Summary:
D65884 added a set of Arm IR intrinsics for the MVE VCTP instruction,
to use in tail predication. But the 64-bit one doesn't work properly:
its predicate type is `<2 x i1>` / `v2i1`, which isn't a legal MVE
type (due to not having a full set of instructions that manipulate it
usefully). The test of `vctp64` in `basic-tail-pred.ll` goes through
`opt` fine, as the test expects, but if you then feed it to `llc` it
causes a type legality failure at isel time.
The usual workaround we've been using in the rest of the MVE
intrinsics family is to bodge `v2i1` into `v4i1`. So I've adjusted the
`vctp64` IR intrinsic to do that, and completely removed the code (and
test) that uses that intrinsic for 64-bit tail predication. That will
allow me to add isel rules (upcoming in D70485) that actually generate
the VCTP64 instruction.
Also renamed all four of these IR intrinsics so that they have `mve`
in the name, since its absence was confusing.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Reviewed By: MarkMurrayARM
Subscribers: samparker, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70592
2019-12-03 00:18:24 +08:00
|
|
|
declare <16 x i1> @llvm.arm.mve.vctp8(i32)
|
|
|
|
declare <8 x i1> @llvm.arm.mve.vctp16(i32)
|
|
|
|
declare <4 x i1> @llvm.arm.mve.vctp32(i32)
|