When we have something like:
MOV OUT[n], IN[m].wzyx
the existing grouping code was missing a potential conflict. Due to
input needing to be sequential scalar regs, we have:
IN: x <-> y <-> z <-> w
which would be grouped to:
OUT: w <-> z2 <-> y2 <-> x (where the 2 denotes a copy/mov)
but that can't actually work. We need to realize that x and w are
already in the same chain, not just that they aren't both already in
new chain being built.
With this fixed, we probably no longer need the hack from
f68f6c0.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
}
static struct group_ops instr_ops = { instr_get, instr_insert_mov };
+/* verify that cur != instr, but cur is also not in instr's neighbor-list: */
+static bool
+in_neighbor_list(struct ir3_instruction *instr, struct ir3_instruction *cur)
+{
+ if (!instr)
+ return false;
+
+ if (instr == cur)
+ return true;
+
+ for (instr = ir3_neighbor_first(instr); instr; instr = instr->cp.right)
+ if (instr == cur)
+ return true;
+
+ return false;
+}
static void
group_n(struct group_ops *ops, void *arr, unsigned n)
/* we also can't have an instr twice in the group: */
for (j = i + 1; (j < n) && !conflict; j++)
- if (ops->get(arr, j) == instr)
+ if (in_neighbor_list(ops->get(arr, j), instr))
conflict = true;
if (conflict) {