On Fri, Apr 6, 2018 at 2:47 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> On Tue, Apr 03, 2018 at 11:32:51AM -0700, Jason Ekstrand wrote:
> > ---
> > src/compiler/nir/nir_lower_system_values.c | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_lower_system_values.c
> b/src/compiler/nir/nir_lower_system_values.c
> > index fb560ee..104df51 100644
> > --- a/src/compiler/nir/nir_lower_system_values.c
> > +++ b/src/compiler/nir/nir_lower_system_values.c
> > @@ -39,10 +39,15 @@ convert_block(nir_block *block, nir_builder *b)
> >
> > nir_intrinsic_instr *load_var = nir_instr_as_intrinsic(instr);
> >
> > - if (load_var->intrinsic != nir_intrinsic_load_var)
> > - continue;
> > + nir_variable *var;
> > + if (load_var->intrinsic == nir_intrinsic_load_var) {
> > + var = load_var->variables[0]->var;
> > + } else if (load_var->intrinsic == nir_intrinsic_load_deref) {
> > + var = nir_deref_instr_get_variable(n
> ir_src_as_deref(load_var->src[0]));
>
> Question: nir_deref_instr_get_variable will walk the deref instr
> chain, but does it even make sense if there's a array or struct in
> this deref chain? Should this be asserted?
>
That's an interesting question. Certainly, at this point in the patch
series, we can't make that assumption. This is because we haven't checked
the mode yet. However, once we can assume deref instructions, we can check
the mode and then go on to find the var. Maybe something like this
(untested):
https://gitlab.freedesktop.org/jekstrand/mesa/commit/33aee39955eff842d6ea263da2f36e60287e62ee
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
