lima/gpir: Disallow moves for schedule_first nodes

The entire point of schedule_first is that the node has to be scheduled
as soon as possible without any moves because it doesn't produce a
proper floating-point value, or its value changes depending on where you
read it. We were still introducing a move for preexp2 in some cases
though, even if it got scheduled as soon as possible, which broke some
exp() tests. Fix that.

Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>

diff --git a/src/gallium/drivers/lima/ir/gp/scheduler.c b/src/gallium/drivers/lima/ir/gp/scheduler.c
index 003dd7d94637574900d5ff6a6c7d28fc755e58ea..076794a48608f176f32d3a17ed149a04dc58a32d 100644 (file)
--- a/src/gallium/drivers/lima/ir/gp/scheduler.c
+++ b/src/gallium/drivers/lima/ir/gp/scheduler.c
@@ -1332,10 +1332,14 @@ static void place_move(sched_ctx *ctx, gpir_node *node)
 /* For next-max nodes, not every node can be offloaded to a move in the
  * complex slot. If we run out of non-complex slots, then such nodes cannot
  * have moves placed for them. There should always be sufficient
- * complex-capable nodes so that this isn't a problem.
+ * complex-capable nodes so that this isn't a problem. We also disallow moves
+ * for schedule_first nodes here.
  */
 static bool can_place_move(sched_ctx *ctx, gpir_node *node)
 {
+   if (gpir_op_infos[node->op].schedule_first)
+      return false;
+
    if (!node->sched.next_max_node)
       return true;