nir: Handle wildcards with casts in copy_prop_vars

If we're propagating a copy from a cast where the copy copies an entire
array, we end up with something like &((S *)ssa_N)->f[*] in the source
where a wildcard has a cast in its parent chain.  If we then try to
propagate the read into a non-wildcard array load, we have to specialize
the wildcard.  This breaks because nir_build_deref_follower() doesn't
handle casts.  Since we know a priori that, because wildcards are only
generated by copy_deref on arrays, we cannot have a cast with a wildcard
parent so simply chasing the source deref to the first wildcard will
ensure that any casts in the deref are handled properly.

Fixes: ba2bd20f87 ("nir: Rework opt_copy_prop_vars to use deref instructions")
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
This commit is contained in:
Faith Ekstrand
2023-04-19 17:18:45 -05:00
committed by Marge Bot
parent ae3b022fa0
commit 15ab4d397f

View File

@@ -790,9 +790,15 @@ specialize_wildcards(nir_builder *b,
nir_deref_path *specific)
{
nir_deref_instr **deref_p = &deref->path[1];
nir_deref_instr *ret_tail = deref->path[0];
for (; *deref_p; deref_p++) {
if ((*deref_p)->deref_type == nir_deref_type_array_wildcard)
break;
ret_tail = *deref_p;
}
nir_deref_instr **guide_p = &guide->path[1];
nir_deref_instr **spec_p = &specific->path[1];
nir_deref_instr *ret_tail = deref->path[0];
for (; *deref_p; deref_p++) {
if ((*deref_p)->deref_type == nir_deref_type_array_wildcard) {
/* This is where things get tricky. We have to search through