[Mesa-dev] [PATCH 5/9] nir: Add a local dead write vars removal pass

Jason Ekstrand jason at jlekstrand.net
Wed Aug 29 20:41:46 UTC 2018


On Wed, Aug 29, 2018 at 3:19 PM Caio Marcelo de Oliveira Filho <
caio.oliveira at intel.com> wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> >> >> +static bool
> >> >> +remove_dead_write_vars_local(struct state *state, nir_block *block)
> >> >> +{
> >> >> +   bool progress = false;
> >> >> +
> >> >> +   struct util_dynarray unused_writes;
> >> >> +   util_dynarray_init(&unused_writes, state->mem_ctx);
> >> >> +
> >> >> +   nir_foreach_instr_safe(instr, block) {
> >> >>
> >> >
> >> > It wouldn't hurt to add a case for call instructions which does a
> barrier
> >> > on everything I mentioned below as well as globals and locals.
> >>
> >> Makes sense.  But I don't get locals are affect?  Is this to cover the
> >> parameters being passed to the call?
> >>
> >
> > Because a deref to a local might be passed in as a parameter.  This is
> the
> > way pass-by-reference works for SPIR-V.
>
> Will the parameter appear to the new function as local too?  If so, will
> they be tagged in a way I can identify the derefs?
>

They'll appear as writes to casts whose source is a load_param intrinsic.


> I'm thinking about what to do with unused writes for locals at the end
> of a function.  If it's the main function, we can just remove them, but
> depending on the answer of the question above, it is not so clear for
> non-main functions.
>

Yeah... That's a bit sticky and I'm not sure what the right answer is.  I
guess we could, in theory, have a new "param" mode which is sort-of like a
local only it crosses function boundaries.  I haven't given that much
though.  However, given that functions are always inlined right now, that's
not something we need to deal with just yet.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180829/a97307be/attachment-0001.html>


More information about the mesa-dev mailing list