[ARM] Mark VMOV with immediate: isAsCheapAsMove.
VMOVs are not strictly speaking cheap, but they are as expensive as a vector
copy (VORR), so we should prefer rematerialization over splitting when it
applies.
rdar://problem/23754176
llvm-svn: 257545
diff --git a/llvm/test/CodeGen/ARM/zero-cycle-zero.ll b/llvm/test/CodeGen/ARM/zero-cycle-zero.ll
index 121a87f..4e8696f 100644
--- a/llvm/test/CodeGen/ARM/zero-cycle-zero.ll
+++ b/llvm/test/CodeGen/ARM/zero-cycle-zero.ll
@@ -1,26 +1,19 @@
-; RUN: llc -mtriple=armv8 -mcpu=cyclone < %s | FileCheck %s --check-prefix=CHECK-CYCLONE
-; RUN: llc -mtriple=armv8 -mcpu=swift < %s | FileCheck %s --check-prefix=CHECK-SWIFT
+; RUN: llc -mtriple=armv8 -mcpu=cyclone < %s | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOTSWIFT
+; RUN: llc -mtriple=armv8 -mcpu=swift < %s | FileCheck %s --check-prefix=CHECK
+; RUN: llc -mtriple=armv8 -mcpu=cortex-a57 < %s | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOTSWIFT
declare arm_aapcs_vfpcc void @take_vec64(<2 x i32>)
define void @test_vec64() {
-; CHECK-CYCLONE-LABEL: test_vec64:
-; CHECK-SWIFT-LABEL: test_vec64:
+; CHECK-LABEL: test_vec64:
call arm_aapcs_vfpcc void @take_vec64(<2 x i32> <i32 0, i32 0>)
call arm_aapcs_vfpcc void @take_vec64(<2 x i32> <i32 0, i32 0>)
-; CHECK-CYCLONE-NOT: vmov.f64 d0,
-; CHECK-CYCLONE: vmov.i32 d0, #0
-; CHECK-CYCLONE: bl
-; CHECK-CYCLONE: vmov.i32 d0, #0
-; CHECK-CYCLONE: bl
-
-; CHECK-SWIFT: vmov.f64 [[ZEROREG:d[0-9]+]],
-; CHECK-SWIFT: vmov.i32 [[ZEROREG]], #0
-; CHECK-SWIFT: vorr d0, [[ZEROREG]], [[ZEROREG]]
-; CHECK-SWIFT: bl
-; CHECK-SWIFT: vorr d0, [[ZEROREG]], [[ZEROREG]]
-; CHECK-SWIFT: bl
+; CHECK-NOTSWIFT-NOT: vmov.f64 d0,
+; CHECK: vmov.i32 d0, #0
+; CHECK: bl
+; CHECK: vmov.i32 d0, #0
+; CHECK: bl
ret void
}
@@ -28,23 +21,15 @@
declare arm_aapcs_vfpcc void @take_vec128(<8 x i16>)
define void @test_vec128() {
-; CHECK-CYCLONE-LABEL: test_vec128:
-; CHECK-SWIFT-LABEL: test_vec128:
+; CHECK-LABEL: test_vec128:
call arm_aapcs_vfpcc void @take_vec128(<8 x i16> <i16 0, i16 0, i16 0, i16 0, i16 0, i16 0, i16 0, i16 0>)
call arm_aapcs_vfpcc void @take_vec128(<8 x i16> <i16 0, i16 0, i16 0, i16 0, i16 0, i16 0, i16 0, i16 0>)
-; CHECK-CYCLONE-NOT: vmov.f64 [[ZEROREG:d[0-9]+]],
-; CHECK-CYCLONE: vmov.i32 q0, #0
-; CHECK-CYCLONE: bl
-; CHECK-CYCLONE: vmov.i32 q0, #0
-; CHECK-CYCLONE: bl
-
-; CHECK-SWIFT-NOT: vmov.f64 [[ZEROREG:d[0-9]+]],
-; CHECK-SWIFT: vmov.i32 [[ZEROREG:q[0-9]+]], #0
-; CHECK-SWIFT: vorr q0, [[ZEROREG]], [[ZEROREG]]
-; CHECK-SWIFT: bl
-; CHECK-SWIFT: vorr q0, [[ZEROREG]], [[ZEROREG]]
-; CHECK-SWIFT: bl
+; CHECK-NOT: vmov.f64 [[ZEROREG:d[0-9]+]],
+; CHECK: vmov.i32 q0, #0
+; CHECK: bl
+; CHECK: vmov.i32 q0, #0
+; CHECK: bl
ret void
}
@@ -52,16 +37,15 @@
declare void @take_i32(i32)
define void @test_i32() {
-; CHECK-CYCLONE-LABEL: test_i32:
-; CHECK-SWIFT-LABEL: test_i32:
+; CHECK-LABEL: test_i32:
call arm_aapcs_vfpcc void @take_i32(i32 0)
call arm_aapcs_vfpcc void @take_i32(i32 0)
-; CHECK-CYCLONE-NOT: vmov.f64 [[ZEROREG:d[0-9]+]],
-; CHECK-CYCLONE: mov r0, #0
-; CHECK-CYCLONE: bl
-; CHECK-CYCLONE: mov r0, #0
-; CHECK-CYCLONE: bl
+; CHECK-NOTSWIFT-NOT: vmov.f64 [[ZEROREG:d[0-9]+]],
+; CHECK: mov r0, #0
+; CHECK: bl
+; CHECK: mov r0, #0
+; CHECK: bl
; It doesn't particularly matter what Swift does here, there isn't carefully
; crafted behaviour that we might break in Cyclone.