llvm-mirror/test/CodeGen/ARM/2012-05-04-vmov.ll

; RUN: llc -O1 -march=arm -mcpu=cortex-a9 < %s | FileCheck -check-prefix=A9-CHECK %s
; RUN: llc -O1 -march=arm -mcpu=swift < %s | FileCheck -check-prefix=SWIFT-CHECK %s
; Check that swift doesn't use vmov.32. <rdar://problem/10453003>.

define <2 x i32> @testuvec(<2 x i32> %A, <2 x i32> %B) nounwind {
entry:
  %div = udiv <2 x i32> %A, %B
  ret <2 x i32> %div
; A9-CHECK: vmov.32
; vmov.32 should not be used to get a lane:
; vmov.32 <dst>, <src>[<lane>].
; but vmov.32 <dst>[<lane>], <src> is fine.
; SWIFT-CHECK-NOT: vmov.32 {{r[0-9]+}}, {{d[0-9]\[[0-9]+\]}}
}
Add LLVM support for Swift. llvm-svn: 164899 2012-09-29 23:43:49 +02:00			`; RUN: llc -O1 -march=arm -mcpu=cortex-a9 < %s \| FileCheck -check-prefix=A9-CHECK %s`
			`; RUN: llc -O1 -march=arm -mcpu=swift < %s \| FileCheck -check-prefix=SWIFT-CHECK %s`
			`; Check that swift doesn't use vmov.32. <rdar://problem/10453003>.`

			`define <2 x i32> @testuvec(<2 x i32> %A, <2 x i32> %B) nounwind {`
			`entry:`
			`%div = udiv <2 x i32> %A, %B`
			`ret <2 x i32> %div`
			`; A9-CHECK: vmov.32`
[ARM] Improve the instruction selection of vector loads. In the ARM back-end, build_vector nodes are lowered to a target specific build_vector that uses floating point type. This works well, unless the inserted bitcasts survive until instruction selection. In that case, they incur moves between integer unit and floating point unit that may result in inefficient code. In other words, this conversion may introduce artificial dependencies when the code leading to the build vector cannot be completed with a floating point type. In particular, this happens when loads are not aligned. Before this patch, in that case, the compiler generates general purpose loads and creates the floating point vector from them, instead of directly using the vector unit. The patch uses a vector friendly sequence of code when the inserted bitcasts to floating point survived DAGCombine. This is done by a target specific DAGCombine that changes the target specific build_vector into a sequence of insert_vector_elt that get rid of the bitcasts. <rdar://problem/14170854> llvm-svn: 185587 2013-07-03 23:42:57 +02:00			`; vmov.32 should not be used to get a lane:`
			`; vmov.32 <dst>, <src>[<lane>].`
			`; but vmov.32 <dst>[<lane>], <src> is fine.`
			`; SWIFT-CHECK-NOT: vmov.32 {{r[0-9]+}}, {{d[0-9]\[[0-9]+\]}}`
Add LLVM support for Swift. llvm-svn: 164899 2012-09-29 23:43:49 +02:00			`}`