<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 3:19 PM Caio Marcelo de Oliveira Filho <<a href="mailto:caio.oliveira@intel.com">caio.oliveira@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
<br>
>> >> +static bool<br>
>> >> +remove_dead_write_vars_local(struct state *state, nir_block *block)<br>
>> >> +{<br>
>> >> +   bool progress = false;<br>
>> >> +<br>
>> >> +   struct util_dynarray unused_writes;<br>
>> >> +   util_dynarray_init(&unused_writes, state->mem_ctx);<br>
>> >> +<br>
>> >> +   nir_foreach_instr_safe(instr, block) {<br>
>> >><br>
>> ><br>
>> > It wouldn't hurt to add a case for call instructions which does a barrier<br>
>> > on everything I mentioned below as well as globals and locals.<br>
>><br>
>> Makes sense.  But I don't get locals are affect?  Is this to cover the<br>
>> parameters being passed to the call?<br>
>><br>
><br>
> Because a deref to a local might be passed in as a parameter.  This is the<br>
> way pass-by-reference works for SPIR-V.<br>
<br>
Will the parameter appear to the new function as local too?  If so, will<br>
they be tagged in a way I can identify the derefs?<br>
</blockquote><div><br></div><div>They'll appear as writes to casts whose source is a load_param intrinsic.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm thinking about what to do with unused writes for locals at the end<br>
of a function.  If it's the main function, we can just remove them, but<br>
depending on the answer of the question above, it is not so clear for<br>
non-main functions. <br></blockquote><div><br></div><div>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.</div><div><br></div><div>--Jason<br></div></div></div>