The dead_cf pass calls into the CF manipulation helpers which attempt to
keep NIR's SSA form sane. However, when the only break is removed from
a loop, dominance gets messed up anyway because the CF SSA clean-up code
only looks at phis and doesn't consider the case of code becoming
unreachable. One solution to this would be to put the loop into LCSSA
form before we modify any of its contents. Another (and the approach
taken by this pass) is to just run the repair_ssa pass afterwards
because the CF manipulation helpers are smart enough to keep all the
use/def stuff sane; they just don't always preserve dominance
properties.
While we're here, we clean up some bogus indentation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111405
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111069
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
if (progress) {
nir_metadata_preserve(impl, nir_metadata_none);
- } else {
+
+ /* The CF manipulation code called by this pass is smart enough to keep
+ * from breaking any SSA use/def chains by replacing any uses of removed
+ * instructions with SSA undefs. However, it's not quite smart enough
+ * to always preserve the dominance properties. In particular, if you
+ * remove the one break from a loop, stuff in the loop may still be used
+ * outside the loop even though there's no path between the two. We can
+ * easily fix these issues by calling nir_repair_ssa which will ensure
+ * that the dominance properties hold.
+ */
+ nir_repair_ssa_impl(impl);
+ } else {
#ifndef NDEBUG
impl->valid_metadata &= ~nir_metadata_not_properly_reset;
#endif
- }
+ }
return progress;
}