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 <jasuarez@igalia.com>
(cherry picked from commit 79dee14cc2)

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13923>

.pick_status.json

@@ -1300,7 +1300,7 @@
         "description": "broadcom/compiler: don't move ldvary earlier if current instruction has ldunif",
         "nominated": false,
         "nomination_type": null,
-        "resolution": 4,
+        "resolution": 1,
         "main_sha": null,
         "because_sha": null
     },

src/broadcom/compiler/qpu_schedule.c

@@ -2001,6 +2001,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.
          */