mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-09-02 11:30:10 +00:00
33957173a7
support transforming the forms from the new vector shuffle lowering to
use 'movddup' when appropriate.
A bunch of the cases where we actually form 'movddup' don't actually
show up in the test results because something even later than DAG
legalization maps them back to 'unpcklpd'. If this shows back up as
a performance problem, I'll probably chase it down, but it is at least
an encoded size loss. =/
To make this work, also always do this canonicalizing step for floating
point vectors where the baseline shuffle instructions don't provide any
free copies of their inputs. This also causes us to canonicalize
unpck[hl]pd into mov{hl,lh}ps (resp.) which is a nice encoding space
win.
There is one test which is "regressed" by this: extractelement-load.
There, the test case where the optimization it is testing *fails*, the
exact instruction pattern which results is slightly different. This
should probably be fixed by having the appropriate extract formed
earlier in the DAG, but that would defeat the purpose of the test.... If
this test case is critically important for anyone, please let me know
and I'll try to work on it. The prior behavior was actually contrary to
the comment in the test case and seems likely to have been an accident.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217738 91177308-0d34-0410-b5e6-96231b3b80d8
49 lines
1.6 KiB
LLVM
49 lines
1.6 KiB
LLVM
; RUN: llc < %s -march=x86 -mattr=+sse2 -mcpu=yonah | FileCheck %s
|
|
; RUN: llc < %s -march=x86-64 -mattr=+sse2 -mcpu=core2 | FileCheck %s
|
|
|
|
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
|
|
define i32 @t(<2 x i64>* %val) nounwind {
|
|
; CHECK-LABEL: t:
|
|
; CHECK-NOT: movd
|
|
; CHECK: movl 8(
|
|
; CHECK-NEXT: ret
|
|
%tmp2 = load <2 x i64>* %val, align 16 ; <<2 x i64>> [#uses=1]
|
|
%tmp3 = bitcast <2 x i64> %tmp2 to <4 x i32> ; <<4 x i32>> [#uses=1]
|
|
%tmp4 = extractelement <4 x i32> %tmp3, i32 2 ; <i32> [#uses=1]
|
|
ret i32 %tmp4
|
|
}
|
|
|
|
; Case where extractelement of load ends up as undef.
|
|
; (Making sure this doesn't crash.)
|
|
define i32 @t2(<8 x i32>* %xp) {
|
|
; CHECK-LABEL: t2:
|
|
; CHECK: ret
|
|
%x = load <8 x i32>* %xp
|
|
%Shuff68 = shufflevector <8 x i32> %x, <8 x i32> undef, <8 x i32> <i32
|
|
undef, i32 7, i32 9, i32 undef, i32 13, i32 15, i32 1, i32 3>
|
|
%y = extractelement <8 x i32> %Shuff68, i32 0
|
|
ret i32 %y
|
|
}
|
|
|
|
; This case could easily end up inf-looping in the DAG combiner due to an
|
|
; low alignment load of the vector which prevents us from reliably forming a
|
|
; narrow load.
|
|
; FIXME: It would be nice to detect whether the target has fast and legal
|
|
; unaligned loads and use them here.
|
|
define void @t3() {
|
|
; CHECK-LABEL: t3:
|
|
;
|
|
; This movs the entire vector, shuffling the high double down. If we fixed the
|
|
; FIXME above it would just move the high double directly.
|
|
; CHECK: movups
|
|
; CHECK: movhlps
|
|
; CHECK: movlps
|
|
|
|
bb:
|
|
%tmp13 = load <2 x double>* undef, align 1
|
|
%.sroa.3.24.vec.extract = extractelement <2 x double> %tmp13, i32 1
|
|
store double %.sroa.3.24.vec.extract, double* undef, align 8
|
|
unreachable
|
|
}
|