llvm-6502/test/CodeGen/PowerPC/unaligned.ll
Bill Schmidt b76f5ba103 [PowerPC] Enable use of lxvw4x/stxvw4x in VSX code generation
Currently the VSX support enables use of lxvd2x and stxvd2x for 2x64
types, but does not yet use lxvw4x and stxvw4x for 4x32 types.  This
patch adds that support.

As with lxvd2x/stxvd2x, this involves straightforward overriding of
the patterns normally recognized for lvx/stvx, with preference given
to the VSX patterns when VSX is enabled.

In addition, the logic for permitting misaligned memory accesses is
modified so that v4r32 and v4i32 are treated the same as v2f64 and
v2i64 when VSX is enabled.  Finally, the DAG generation for unaligned
loads is changed to just use a normal LOAD (which will become lxvw4x)
on P8 and later hardware, where unaligned loads are preferred over
lvsl/lvx/lvx/vperm.

A number of tests now generate the VSX loads/stores instead of
lvx/stvx, so this patch adds VSX variants to those tests.  I've also
added <4 x float> tests to the vsx.ll test case, and created a
vsx-p8.ll test case to be used for testing code generation for the
P8Vector feature.  For now, that simply tests the unaligned load/store
behavior.

This has been tested along with a temporary patch to enable the VSX
and P8Vector features, with no new regressions encountered with or
without the temporary patch applied.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220047 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-17 15:13:38 +00:00

106 lines
2.3 KiB
LLVM

; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 -mattr=-vsx | FileCheck %s
target datalayout = "E-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f128:64:128-n32"
; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 -mattr=+vsx | FileCheck -check-prefix=CHECK-VSX %s
target datalayout = "E-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f128:64:128-n32"
define void @foo1(i16* %p, i16* %r) nounwind {
entry:
%v = load i16* %p, align 1
store i16 %v, i16* %r, align 1
ret void
; CHECK: @foo1
; CHECK: lhz
; CHECK: sth
; CHECK-VSX: @foo1
; CHECK-VSX: lhz
; CHECK-VSX: sth
}
define void @foo2(i32* %p, i32* %r) nounwind {
entry:
%v = load i32* %p, align 1
store i32 %v, i32* %r, align 1
ret void
; CHECK: @foo2
; CHECK: lwz
; CHECK: stw
; CHECK-VSX: @foo2
; CHECK-VSX: lwz
; CHECK-VSX: stw
}
define void @foo3(i64* %p, i64* %r) nounwind {
entry:
%v = load i64* %p, align 1
store i64 %v, i64* %r, align 1
ret void
; CHECK: @foo3
; CHECK: ld
; CHECK: std
; CHECK-VSX: @foo3
; CHECK-VSX: ld
; CHECK-VSX: std
}
define void @foo4(float* %p, float* %r) nounwind {
entry:
%v = load float* %p, align 1
store float %v, float* %r, align 1
ret void
; CHECK: @foo4
; CHECK: lfs
; CHECK: stfs
; CHECK-VSX: @foo4
; CHECK-VSX: lfs
; CHECK-VSX: stfs
}
define void @foo5(double* %p, double* %r) nounwind {
entry:
%v = load double* %p, align 1
store double %v, double* %r, align 1
ret void
; CHECK: @foo5
; CHECK: lfd
; CHECK: stfd
; CHECK-VSX: @foo5
; CHECK-VSX: lxsdx
; CHECK-VSX: stxsdx
}
define void @foo6(<4 x float>* %p, <4 x float>* %r) nounwind {
entry:
%v = load <4 x float>* %p, align 1
store <4 x float> %v, <4 x float>* %r, align 1
ret void
; These loads and stores are legalized into aligned loads and stores
; using aligned stack slots.
; CHECK: @foo6
; CHECK-DAG: ld
; CHECK-DAG: ld
; CHECK-DAG: stdx
; CHECK: stdx
; For VSX on P7, unaligned loads and stores are preferable to aligned
; stack slots, but lvsl/vperm is better still. (On P8 lxvw4x is preferable.)
; Using unaligned stxvw4x is preferable on both machines.
; CHECK-VSX: @foo6
; CHECK-VSX-DAG: lvsl
; CHECK-VSX-DAG: lvx
; CHECK-VSX-DAG: lvx
; CHECK-VSX: vperm
; CHECK-VSX: stxvw4x
}