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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48206 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/CodeGen/PowerPC/int-fp-conv.ll b/test/CodeGen/PowerPC/int-fp-conv-0.ll
similarity index 100%
rename from test/CodeGen/PowerPC/int-fp-conv.ll
rename to test/CodeGen/PowerPC/int-fp-conv-0.ll
diff --git a/test/CodeGen/PowerPC/int-fp-conv-1.ll b/test/CodeGen/PowerPC/int-fp-conv-1.ll
new file mode 100644
index 0000000..3d66675
--- /dev/null
+++ b/test/CodeGen/PowerPC/int-fp-conv-1.ll
@@ -0,0 +1,11 @@
+; RUN: llvm-as < %s | llc -march=ppc64 | grep __floatditf
+
+define i64 @__fixunstfdi(ppc_fp128 %a) nounwind {
+entry:
+ %tmp1213 = uitofp i64 0 to ppc_fp128 ; <ppc_fp128> [#uses=1]
+ %tmp15 = sub ppc_fp128 %a, %tmp1213 ; <ppc_fp128> [#uses=1]
+ %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
+}