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/int-fp-conv-1.ll

13 lines
465 B
LLVM
Raw Normal View History

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-04 02:17:35 +08:00
; RUN: llc -verify-machineinstrs < %s -march=ppc64 | FileCheck %s
In various places throughout the code generator, there were special checks to avoid performing compile-time arithmetic on PPCDoubleDouble. Now that APFloat supports arithmetic on PPCDoubleDouble, those checks are no longer needed, and we can treat the type like any other. llvm-svn: 166958
2012-10-30 02:35:49 +08:00
; CHECK-NOT: __floatditf
Generalize ExpandIntToFP to handle the case where the operand is legal and it's the result that requires expansion. This code is a little confusing because the TargetLoweringInfo tables for [US]INT_TO_FP use the operand type (the integer type) rather than the result type. llvm-svn: 48206
2008-03-11 09:59:03 +08:00
define i64 @__fixunstfdi(ppc_fp128 %a) nounwind {
entry:
%tmp1213 = uitofp i64 0 to ppc_fp128 ; <ppc_fp128> [#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
%tmp15 = fsub ppc_fp128 %a, %tmp1213 ; <ppc_fp128> [#uses=1]
Generalize ExpandIntToFP to handle the case where the operand is legal and it's the result that requires expansion. This code is a little confusing because the TargetLoweringInfo tables for [US]INT_TO_FP use the operand type (the integer type) rather than the result type. llvm-svn: 48206
2008-03-11 09:59:03 +08:00
%tmp2829 = fptoui ppc_fp128 %tmp15 to i32 ; <i32> [#uses=1]
%tmp282930 = zext i32 %tmp2829 to i64 ; <i64> [#uses=1]
%tmp32 = add i64 %tmp282930, 0 ; <i64> [#uses=1]
ret i64 %tmp32
}