[Mesa-dev] [PATCH 00/61] nir: Move to using instructions for derefs

[Jason Ekstrand]

On March 29, 2018 06:44:59 Rob Clark <robdclark at gmail.com> wrote:

On Wed, Mar 28, 2018 at 9:41 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:

On March 28, 2018 17:43:31 Rob Clark <robdclark at gmail.com> wrote:

On Wed, Mar 28, 2018 at 8:16 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:
On March 28, 2018 16:54:33 Rob Clark <robdclark at gmail.com> wrote:

I had noticed the code to remove dead deref's in a few of the passes
(at least on your wip branch), and had wondered a bit about not just
requiring all the deref related lowering to happen in ssa and possibly
require dce after, although admittedly hadn't thought about it *too*
much yet..

Yeah. Like I said below, it should be ready enough to just have a tiny
clean-up pass instead of having to run full-on dce.  Maybe just running dce
is the right choice; I'm not sure.


I kinda expected to use the dce clean things up once we are in a
deref-instruction world.. re: validation passes, could we not just
allow dead deref instructions to be ok.  That seems like kind of a
natural thing..

Making validation ignore them is easy. The trickier bit is that they can
cause problems for any pass which works on all deref instructions as opposed
to working on texture instructions or intrinsics and tracing the deref chain
back.  The later are ok because they'll never look at dead derefs.  There
former (which are likely to be more efficient if we've CSEd derefs) can run
into trouble as it's not always obvious when a deref is dead.

I'm sure I'll get a better feel for this whole mess as I continue to
progress.

Defn not trying to second guess you since you are deeper into it that
I am..  But requiring dce (or a some sort of mini deref-dce) pass in
various places seems reasonable.. I guess it would be nice (given the
growing list of nir passes) to have some more formal way to require
that some pass(es) is run prior to a whatever random pass driver wants
to run would be nice.  (Not sure if llvm's PassManager provides this..
if it doesn't, it should.)

Yeah.  We could theoretically use the metadata system for this but it seems
like a bit of an abuse.  I'll know more once I get done removing deref
chains.  That process is teaching me about all sorts of things I missed on
the first pass.

mmm, I wouldn't look at it as an abuse, as much as making the metadata
system a bit more generic.  Metadata is really a subset of "state of
the IR".  (Although perhaps that means nir_metadata_* is no longer a
good name ;-))

By abuse, I mostly meant that the metadata system currently never alters 
the IR beyond filling in extra metadata.  But extending it to run dead code 
is probably the safest IR-modifying thing one can do


But this doesn't all have to be done at once.. merging addition of
deref instructions with (nearly) immediate lowering to deref chains
seems relatively safe (piglit was happy) and low impact on drivers.
And would be helpful for clover / vtn pointer (ie. not having to
rebase on top of two large patchsets)

Yup.  I would like to finish the removal (for Intel drivers) before 
anything gets merged just because it's been so informative when it comes to 
telling me about all the things I missed.  Review can start at any time though.

--Jason