nir/opt_reassociate: fix exactness bug

For an inexact-associative operation (fadd or fmul), can_reassociate ensures the
root of the chain is inexact to allow reassociating. However, build_chain just
checks for opcodes to match up after, although we do sum up exactness across the
chain. Although an Effort Was Made, it still seems incorrect to reassociate

   %3 = fadd! %0, %1
   %4 = fadd %3, %2

to instead be (ex.)

   %3 = fadd! %0, %2
   %4 = fadd! %3, %1

Closes: #14418
Fixes: e0b0f7e73c ("nir: add ALU reassocation pass")
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41162>
This commit is contained in:
Alyssa Rosenzweig 2026-04-15 17:21:38 -04:00 committed by Marge Bot
parent 2b6db10f38
commit 0c49738211

View file

@ -227,6 +227,7 @@ build_chain(struct chain *c, nir_scalar def, unsigned reserved_count)
unsigned reserved_plus_remaining = reserved_count + remaining;
if (nir_scalar_is_alu(src) && nir_scalar_alu_op(src) == alu->op &&
can_reassociate(nir_def_as_alu(src.def)) &&
list_is_singular(&src.def->uses) &&
c->length + reserved_plus_remaining + 2 <= MAX_CHAIN_LENGTH) {