mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-10-31 08:16:47 +00:00
8e2e5ff024
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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185587 91177308-0d34-0410-b5e6-96231b3b80d8
15 lines
565 B
LLVM
15 lines
565 B
LLVM
; 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]+\]}}
|
|
}
|