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>
(cherry picked from commit 0c49738211)

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

.pick_status.json

@@ -574,7 +574,7 @@
         "description": "nir/opt_reassociate: fix exactness bug",
         "nominated": true,
         "nomination_type": 2,
-        "resolution": 0,
+        "resolution": 1,
         "main_sha": null,
         "because_sha": "e0b0f7e73c88f63472cdaedf01b428e6a824d5de",
         "notes": null

src/compiler/nir/nir_opt_reassociate.c

@@ -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) {