From 79dee14cc218d87ea8a5020507161a363477f09a Mon Sep 17 00:00:00 2001 From: Iago Toral Quiroga Date: Tue, 23 Nov 2021 08:49:53 +0100 Subject: [PATCH] broadcom/compiler: don't move ldvary earlier if current instruction has ldunif If we did, we would have the instruction coming right after ldvary write to the same implicit destination as ldvary at the same time. We prevent this when merging instructions, but we should make sure we prevent this when we move ldvary around for pipelining too. Reviewed-by: Juan A. Suarez Part-of: --- src/broadcom/compiler/qpu_schedule.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/broadcom/compiler/qpu_schedule.c b/src/broadcom/compiler/qpu_schedule.c index 08085eea40e..6fd27b42e90 100644 --- a/src/broadcom/compiler/qpu_schedule.c +++ b/src/broadcom/compiler/qpu_schedule.c @@ -2036,6 +2036,17 @@ fixup_pipelined_ldvary(struct v3d_compile *c, if (alu_reads_register(inst, false, ldvary_magic, ldvary_index)) return false; + /* The implicit ldvary destination may not be written to by a signal + * in the instruction following ldvary. Since we are planning to move + * ldvary to the previous instruction, this means we need to check if + * the current instruction has any other signal that could create this + * conflict. The only other signal that can write to the implicit + * ldvary destination that is compatible with ldvary in the same + * instruction is ldunif. + */ + if (inst->sig.ldunif) + return false; + /* The previous instruction can't write to the same destination as the * ldvary. */