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 <[email protected]>
Tested-by: Vasily Khoruzhick <[email protected]>

1 files changed, 5 insertions, 1 deletions

diff --git a/src/gallium/drivers/lima/ir/gp/scheduler.c b/src/gallium/drivers/lima/ir/gp/scheduler.c
index 003dd7d9463..076794a4860 100644
--- 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;