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

2 files changed, 11 insertions, 0 deletions

diff --git a/llvm/test/CodeGen/PowerPC/int-fp-conv.ll b/llvm/test/CodeGen/PowerPC/int-fp-conv-0.ll
index 82a18268514..82a18268514 100644
--- a/llvm/test/CodeGen/PowerPC/int-fp-conv.ll
+++ b/llvm/test/CodeGen/PowerPC/int-fp-conv-0.ll
diff --git a/llvm/test/CodeGen/PowerPC/int-fp-conv-1.ll b/llvm/test/CodeGen/PowerPC/int-fp-conv-1.ll
new file mode 100644
index 00000000000..3d6667539f2
--- /dev/null
+++ b/llvm/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
+}