Skip to content

intel/compiler: Don't call nir_opt_remove_phis before nir_convert_from_ssa

Ian Romanick requested to merge idr/mesa:review/no-nir_opt_remove_phis into main

There are two parts to this MR that seem unrelated, but the first is needed for the second to succeed. I will describe them in reverse order.

As noted in #10727 (closed), the Intel compiler calls nir_opt_remove_phis after entering LCSSA form and performing divergence analysis. However, nir_opt_remove_phis breaks both LCSSA form and divergence analysis. Proper divergence information is needed for nir_convert_from_ssa. Removing nir_opt_remove_phis does affect some shaders in shader-db and fossil-db. There is a little more information in the linked issue. So, we need to stop calling that pass at this point in compilation.

Unfortunately, intel_nir_lower_non_uniform_barycentric_at_sample implicitly depended on having trivial phis removed by that pass. With the phis removed, later code generation would examine the source of the load_interpolated_input to see the load_barycentric_at_sample. This would be used to determine the interpolation mode. When the trivial phis are not removed, the load_interpolated_input instead sees a load_reg.

I tried a couple strategies to avoid moving the load_interpolated_input inside the loop, but none of them worked. Having that instruction inside the divergent control flow inside the loop can have a performance penalty, but zero shaders in shader-db or fossil-db hit this path.

I discovered this because removing these seeming trivial phis combined with my fs-scalar branch breaks some test cases. All of the broken cases had trivial phis marked divergent with a single source that was not divergent. It might be possible to work around all of these issues by changing nir_opt_remove_phis to just not remove those kinds of phis. That seems sketchy to me, so I did not pursue it.

Merge request reports