llvm-mirror/test/CodeGen/PowerPC/buildvec_canonicalize.ll

; RUN: llc -verify-machineinstrs < %s -mattr=-vsx -march=ppc32 -mattr=+altivec --enable-unsafe-fp-math | FileCheck %s

define void @VXOR(<4 x float>* %P1, <4 x i32>* %P2, <4 x float>* %P3) {
        %tmp = load <4 x float>, <4 x float>* %P3            ; <<4 x float>> [#uses=1]
        %tmp3 = load <4 x float>, <4 x float>* %P1           ; <<4 x float>> [#uses=1]
        %tmp4 = fmul <4 x float> %tmp, %tmp3             ; <<4 x float>> [#uses=1]
        store <4 x float> %tmp4, <4 x float>* %P3
        store <4 x float> zeroinitializer, <4 x float>* %P1
        store <4 x i32> zeroinitializer, <4 x i32>* %P2
        ret void
}
; 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

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
        ret void
}
; CHECK: @VSPLTI
; CHECK: vsplti
Adding -verify-machineinstrs option to PowerPC tests Currently we have a number of tests that fail with -verify-machineinstrs. To detect this cases earlier we add the option to the testcases with the exception of tests that will currently fail with this option. PR 27456 keeps track of this failures. No code review, as discussed with Hal Finkel. llvm-svn: 277624 2016-08-03 20:17:35 +02:00			`; RUN: llc -verify-machineinstrs < %s -mattr=-vsx -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-12 19:36:04 +02:00
Byebye llvm-upgrade! llvm-svn: 48762 2008-03-25 05:26:08 +01:00			`define void @VXOR(<4 x float>* %P1, <4 x i32>* %P2, <4 x float>* %P3) {`
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=\|:\|^)\sload (?:atomic )?(?:volatile )?(.?))(\| addrspace\(\d+\) )\($\| (?:%\|@\|null\|undef\|blockaddress\|getelementptr\|addrspacecast\|bitcast\|inttoptr\|\[\[[a-zA-Z]\|\{\{).$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794 2015-02-27 22:17:42 +01:00			`%tmp = load <4 x float>, <4 x float>* %P3 ; <<4 x float>> [#uses=1]`
			`%tmp3 = load <4 x float>, <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 00:49:04 +02: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-12 18:57:39 +02:00			`store <4 x float> %tmp4, <4 x float>* %P3`
new testcase llvm-svn: 27608 2006-04-12 18:49:16 +02:00			`store <4 x float> zeroinitializer, <4 x float>* %P1`
Byebye llvm-upgrade! llvm-svn: 48762 2008-03-25 05:26:08 +01:00			`store <4 x i32> zeroinitializer, <4 x i32>* %P2`
new testcase llvm-svn: 27608 2006-04-12 18:49:16 +02: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 14:05:44 +01: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-12 18:49:16 +02:00
Byebye llvm-upgrade! llvm-svn: 48762 2008-03-25 05:26:08 +01: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-12 19:36:04 +02: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 14:05:44 +01:00			`; CHECK: @VSPLTI`
			`; CHECK: vsplti`