nir/flrp: Lower flrp(a, b, #c) differently
authorIan Romanick <ian.d.romanick@intel.com>
Sat, 18 Aug 2018 23:53:55 +0000 (16:53 -0700)
committerIan Romanick <ian.d.romanick@intel.com>
Tue, 7 May 2019 05:52:29 +0000 (22:52 -0700)
This doesn't help on Intel GPUs now because we always take the
"always_precise" path first.  It may help on other GPUs, and it does
prevent a bunch of regressions in "intel/compiler: Don't always require
precise lowering of flrp".

Reviewed-by: Matt Turner <mattst88@gmail.com>
src/compiler/nir/nir_lower_flrp.c

index 5094a714504dbdf521f18524b11b38821294d1a8..31969a61c794ede8bbb1ed9086f9f70346ac3ec7 100644 (file)
@@ -555,6 +555,23 @@ convert_flrp_instruction(nir_builder *bld,
       }
    }
 
+   /*
+    * - If t is constant:
+    *
+    *        x(1 - t) + yt
+    *
+    *   The cost is three instructions without FMA or two instructions with
+    *   FMA.  This is the same cost as the imprecise lowering, but it gives
+    *   the instruction scheduler a little more freedom.
+    *
+    *   There is no need to handle t = 0.5 specially.  nir_opt_algebraic
+    *   already has optimizations to convert 0.5x + 0.5y to 0.5(x + y).
+    */
+   if (alu->src[2].src.ssa->parent_instr->type == nir_instr_type_load_const) {
+      replace_with_strict(bld, dead_flrp, alu);
+      return;
+   }
+
    /*
     * - Otherwise
     *