[PATCH] [MIPS] OperationAction for FP_TO_FP16, FP16_TO_FP

[Daniel Sanders]

LGTM with a small nit in the test.


================
Comment at: lib/Target/Mips/MipsISelLowering.cpp:226-229
@@ -226,1 +225,6 @@
+  // for f32, f16
+  for (MVT VT : MVT::fp_valuetypes()) {
     setLoadExtAction(ISD::EXTLOAD, VT, MVT::f32, Expand);
+    setLoadExtAction(ISD::EXTLOAD, VT, MVT::f16, Expand);
+  }
+
----------------
While iterating, this will do 3 strange calls:
  setLoadExtAction(ISD::EXTLOAD, MVT::f16, MVT::f32, Expand);
  setLoadExtAction(ISD::EXTLOAD, MVT::f16, MVT::f16, Expand);
  setLoadExtAction(ISD::EXTLOAD, MVT::f32, MVT::f32, Expand);
I assume it isn't a problem to do this since EXTLOAD doesn't make sense when the memory type is larger (or the same as) the value type. It might be better to list the valid cases like we do for setTruncStoreAction() below. I don't mind which approach is taken.

================
Comment at: test/CodeGen/Mips/fp16-promote.ll:3-5
@@ +2,5 @@
+
+target datalayout = "E-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-n32-S64"
+target triple = "mips--linux-gnu"
+
+; CHECK-LIBCALL-LABEL: test_fadd:
----------------
Nit: These two lines aren't necessary and it's best not to duplicate the datalayout in the test in case we ever change it. The bit I think might change at some point is the vector part since our vectors only require the elements to be aligned and not the whole vector.

================
Comment at: test/CodeGen/Mips/fp16-promote.ll:64-71
@@ +63,10 @@
+; CHECK-LIBCALL-LABEL: test_vec_fpext_double:
+; CHECK-LIBCALL: %call16(__gnu_h2f_ieee)
+; CHECK-LIBCALL: %call16(__gnu_h2f_ieee)
+; CHECK-LIBCALL: %call16(__gnu_h2f_ieee)
+; CHECK-LIBCALL: cvt.d.s
+; CHECK-LIBCALL: cvt.d.s
+; CHECK-LIBCALL: cvt.d.s
+; CHECK-LIBCALL: %call16(__gnu_h2f_ieee)
+; CHECK-LIBCALL: cvt.d.s
+define <4 x double> @test_vec_fpext_double(<4 x half>* %p) #0 {
----------------
Just a comment, no change required: This might be a little fragile (the exact order of the output may vary) but I don't see a good way to make it more robust at the moment.

http://reviews.llvm.org/D8804

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