From c64f30546d87a19e2aec34e202919571e9b0c868 Mon Sep 17 00:00:00 2001 From: Connor Abbott Date: Sun, 8 Sep 2019 18:48:35 +0200 Subject: [PATCH] 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 Tested-by: Vasily Khoruzhick --- src/gallium/drivers/lima/ir/gp/scheduler.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) 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; -- 2.30.2