intel/fs: Fix NULL destinations on 3-source instructions again after late DCE

We considered moving this down near the call to
insert_gen4_send_dependency_workarounds.  By that point it's too late
for a couple reasons.  One, we're potentially increasing resiter
pressure that may lead to anoter spill.  Two, fixup_3src_null_dest tries
to allocate a VGRF, but the post-register allocation shader uses
physical registers.

Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2621
Fixes: ba2fa1ceaf ("intel/fs: Do cmod prop again after scheduling")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4155>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4155>

src/intel/compiler/brw_fs.cpp

@@ -7833,8 +7833,15 @@ fs_visitor::allocate_registers(unsigned min_dispatch_width, bool allow_spilling)
       const int iteration = 99;
       int pass_num = 0;
 
-      if (OPT(opt_cmod_propagation))
-         OPT(dead_code_eliminate);
+      if (OPT(opt_cmod_propagation)) {
+         /* dead_code_eliminate "undoes" the fixing done by
+          * fixup_3src_null_dest, so we have to do it again if
+          * dead_code_eliminiate makes any progress.
+          */
+         if (OPT(dead_code_eliminate))
+            fixup_3src_null_dest();
+      }
+
 
       /* We only allow spilling for the last schedule mode and only if the
        * allow_spilling parameter and dispatch width work out ok.