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/ppcf128-4.ll

11 lines
381 B
LLVM
Raw Normal View History

PowerPC: Do not use llc -march in tests. `llc -march` is problematic because it only switches the target architecture, but leaves the operating system unchanged. This occasionally leads to indeterministic tests because the OS from LLVM_DEFAULT_TARGET_TRIPLE is used. However we can simply always use `llc -mtriple` instead. This changes all the tests to do this to avoid people using -march when they copy and paste parts of tests. This patch: - Removes -march if the .ll file already has a matching `target triple` directive or -mtriple argument. - In all other cases changes -march=ppc32/-march=ppc64 to -mtriple=ppc32--/-mtriple=ppc64-- See also the discussion in https://reviews.llvm.org/D35287 llvm-svn: 309754
2017-08-02 06:20:41 +08:00
; RUN: llc -verify-machineinstrs < %s -mtriple=ppc32--
New testcase. llvm-svn: 48697
2008-03-23 06:27:01 +08:00
define ppc_fp128 @__floatditf(i64 %u) nounwind {
entry:
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
%tmp6 = fmul ppc_fp128 0xM00000000000000000000000000000000, 0xM41F00000000000000000000000000000
New testcase. llvm-svn: 48697
2008-03-23 06:27:01 +08:00
%tmp78 = trunc i64 %u to i32
%tmp789 = uitofp i32 %tmp78 to ppc_fp128
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
%tmp11 = fadd ppc_fp128 %tmp789, %tmp6
New testcase. llvm-svn: 48697
2008-03-23 06:27:01 +08:00
ret ppc_fp128 %tmp11
}