intel/fs: Fix NULL destinations on 3-source instructions again after late DCE
authorIan Romanick <ian.d.romanick@intel.com>
Wed, 11 Mar 2020 22:53:23 +0000 (15:53 -0700)
committerIan Romanick <ian.d.romanick@intel.com>
Thu, 12 Mar 2020 15:22:43 +0000 (08:22 -0700)
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: ba2fa1ceaf4 ("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

index b2a563fd94ecf7e54b45e83c788f3872aed57b33..d20af30b32d961ae57fc4c419e233fcd1adff5c9 100644 (file)
@@ -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.