[PATCH] Add support to promote f16 to f32

[Pirama Arumuga Nainar]

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:1604
@@ +1603,3 @@
+
+  assert (false && "Attempt at an invalid promotion-related conversion");
+  return ISD::DELETED_NODE;
----------------
ab wrote:
> llvm_unreachable, or better still, report_fatal_error, as this is actually reachable from purpose-crafted IR?  Same below.
I'll switch to report_fatal_error.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:1608
@@ +1607,3 @@
+
+static RTLIB::Libcall GetPromotionLibcall(EVT OpVT, EVT RetVT) {
+  if (OpVT == MVT::f16) {
----------------
ab wrote:
> As I said on the ML, not sure if it'll work, but you should just let the ops legalizer pick a libcall for the FP_TO_FP nodes.
http://reviews.llvm.org/D8804 should let the Op legalizer do the right thing for Mips.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:1626
@@ +1625,3 @@
+
+static SDValue GetPromotedValue(SelectionDAG &DAG, const TargetLowering &TLI,
+                                const SDValue &Operand, EVT OpVT, EVT RetVT,
----------------
ab wrote:
> I didn't notice this, and found the name a bit confusing, thinking this was some magic legalizer method.  Might be good to have a more descriptive name, making it explicit we actually promote here, rather than get a previously promoted value as GetPromotedInt/Float does.
> 
> The fact that it goes both ways is also a bit confusing, but I get that avoids duplication.  For such a short function, it might be worth doing two separate versions, perhaps?
I'll remove this function and directly use DAG.getNode at its callers - since libcalls are no longer handled here.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:1700
@@ +1699,3 @@
+  // If node's operand is itself an extend/promotion operation, directly promote
+  // to VT.  For e.g., convert f16 -> f32 -> f64 to f16 -> f64.
+  if (Op.getNode()->getOpcode() == ISD::FP16_TO_FP) {
----------------
ab wrote:
> I'm not sure what to think of this.  Could we catch this in a DAGCombine instead?
I'll attempt to do this in the DAGCombiner.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:1982
@@ +1981,3 @@
+  // Round promoted float to desired precision
+  SDValue Round = GetPromotedValue(DAG, TLI, Op, NVT, VT, dl);
+  // Promote it back to the legal output type
----------------
ab wrote:
> I don't follow.  This is about rounding to integers, and has nothing to do with FP, right?  Why not simply GetPromotedFloat?  Or, for that matter, just reusing PromoteFloatRes_UnaryOp.
I couldn't find any documentation or reference for this opcode code.  So, I assumed it was similar to float rounding, while at the same time wondering the difference between FROUND and FTRUNC.  I'll reuse PromoteFloatRes_UnaryOp for FTRUNC.

The above function still applies to FROUND.  I am trying to trim the extra precision as this node be an explicit operation to reduce precision.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeTypes.h:512
@@ +511,3 @@
+
+  SDValue GetPromotedFloat(SDValue Op) {
+    SDValue &PromotedOp = PromotedFloats[Op];
----------------
ab wrote:
> Move this to the .cpp?
I'll leave it here to be consistent with the other GetPromotedInteger and similar functions in this file.

http://reviews.llvm.org/D8755

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/