[Mesa-dev] [PATCH 05/11] nir: Separate dead write removal into its own pass
Jason Ekstrand
jason at jlekstrand.net
Mon Oct 15 19:41:30 UTC 2018
Cool, thanks!
On Mon, Oct 15, 2018 at 2:38 PM Caio Marcelo de Oliveira Filho <
caio.oliveira at intel.com> wrote:
> > > > > +{
> > > > > + bool progress = false;
> > > > > +
> > > > > + /* Find writes that are unused and can be removed. */
> > > > > + util_dynarray_foreach_reverse(unused_writes, struct
> write_entry,
> > > > > entry) {
> > > > > + nir_deref_compare_result comp = nir_compare_derefs(dst,
> > > entry->dst);
> > > > > + if (comp & nir_derefs_a_contains_b_bit) {
> > > > >
> > > >
> > > > Mind throwing an assert in here:
> > > >
> > > > assert((comp & nir_derefs_equal_bit) || mask ==
> > > ~(nir_component_mask_t)0);
> > >
> > > We can assert that. We can have an entry for a copy between arrays a
> > > and b, and see a store a[1].x that will invalidate the 'x' component
> > > of the copy.
> > >
> >
> > Do you mean, "we can't assert that"?
>
> Correct. I meant "we can't".
>
>
> > I'm trying to think about whether or not the type of per-component
> > invalidation you're talking about there is valid or not. If we can
> assume
> > that all struct copies are split and that all copies are fully qualified
> > (i.e., they end in a vector or scalar with wildcards for all the arrays),
> > then I think such inference is fine. Maybe worth a comment that such is
> > intentional?
>
> I've added the following comment and assert to update_unused_writes()
>
> /* This pass assumes that destination of copies and stores are derefs
> that
> * end in a vector or scalar (it is OK to have wildcards or indirects
> for
> * arrays).
> */
> assert(glsl_type_is_vector_or_scalar(dst->type));
>
> My understanding is that in this context this always is true, but in
> the future might not be if we do things like: "copy a b" instead of
> "copy a[*] b[*]" when a and b are arrays (similar to structs).
>
> Updated my branch with that too.
>
>
>
> Caio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181015/42f22ba6/attachment.html>
More information about the mesa-dev
mailing list