maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/PowerPC/buildvec_canonicalize.ll

25 lines
1.1 KiB
LLVM
Raw Normal View History

test/CodeGen/PowerPC: Add explicit -march=ppc32. FIXME: Please add another RUN line if you would like to check also on ppc64. llvm-svn: 168999
2012-11-30 21:28:31 +08:00
; RUN: llc < %s -march=ppc32 -mattr=+altivec --enable-unsafe-fp-math | FileCheck %s
two equivalent vsplti*s in different types should be CSEd. llvm-svn: 27613
2006-04-13 01:36:04 +08:00
Byebye llvm-upgrade! llvm-svn: 48762
2008-03-25 12:26:08 +08:00
define void @VXOR(<4 x float>* %P1, <4 x i32>* %P2, <4 x float>* %P3) {
%tmp = load <4 x float>* %P3 ; <<4 x float>> [#uses=1]
%tmp3 = load <4 x float>* %P1 ; <<4 x float>> [#uses=1]
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
2009-06-05 06:49:04 +08:00
%tmp4 = fmul <4 x float> %tmp, %tmp3 ; <<4 x float>> [#uses=1]
Make this test more interesting by checking that the 0.0 used to implement vector fmul gets cse'd also. llvm-svn: 27610
2006-04-13 00:57:39 +08:00
store <4 x float> %tmp4, <4 x float>* %P3
new testcase llvm-svn: 27608
2006-04-13 00:49:16 +08:00
store <4 x float> zeroinitializer, <4 x float>* %P1
Byebye llvm-upgrade! llvm-svn: 48762
2008-03-25 12:26:08 +08:00
store <4 x i32> zeroinitializer, <4 x i32>* %P2
new testcase llvm-svn: 27608
2006-04-13 00:49:16 +08:00
ret void
}
This patch fixes the Altivec addend construction for the fused multiply-add instruction (vmaddfp) to conform with IEEE to ensure the sign of a zero result when resulting product is -0.0. The -0.0 vector addend to vmaddfp is generated by a creating a vector with full bits sets and then shifting each elements by 31-bits to the left, resulting in a vector of 0x80000000 (or -0.0 as float). The 'buildvec_canonicalize.ll' was adjusted to reflect this change and the 'vec_mul.ll' was complemented with the float vector multiplication test. llvm-svn: 168998
2012-11-30 21:05:44 +08:00
; The fmul will spill a vspltisw to create a -0.0 vector used as the addend
; to vmaddfp (so it would IEEE compliant with zero sign propagation).
; CHECK: @VXOR
; CHECK: vsplti
; CHECK: vxor
new testcase llvm-svn: 27608
2006-04-13 00:49:16 +08:00
Byebye llvm-upgrade! llvm-svn: 48762
2008-03-25 12:26:08 +08:00
define void @VSPLTI(<4 x i32>* %P2, <8 x i16>* %P3) {
store <4 x i32> bitcast (<16 x i8> < i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1 > to <4 x i32>), <4 x i32>* %P2
store <8 x i16> < i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1 >, <8 x i16>* %P3
two equivalent vsplti*s in different types should be CSEd. llvm-svn: 27613
2006-04-13 01:36:04 +08:00
ret void
}
This patch fixes the Altivec addend construction for the fused multiply-add instruction (vmaddfp) to conform with IEEE to ensure the sign of a zero result when resulting product is -0.0. The -0.0 vector addend to vmaddfp is generated by a creating a vector with full bits sets and then shifting each elements by 31-bits to the left, resulting in a vector of 0x80000000 (or -0.0 as float). The 'buildvec_canonicalize.ll' was adjusted to reflect this change and the 'vec_mul.ll' was complemented with the float vector multiplication test. llvm-svn: 168998
2012-11-30 21:05:44 +08:00
; CHECK: @VSPLTI
; CHECK: vsplti