[Mesa-dev] [Bug 109603] nir_instr_as_deref: Assertion `parent && parent->type == nir_instr_type_deref' failed.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=109603

Jason Ekstrand <jason at jlekstrand.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jason Ekstrand <jason at jlekstrand.net> ---
This has been fixed by the following commit in master:

commit 9e6a6ef0d45a5bb61a541c495fe12e54e646ecfe (public/master)
Author: Jason Ekstrand <jason.ekstrand at intel.com>
Date:   Sun Feb 10 22:23:01 2019 -0600

    nir/deref: Rematerialize parents in rematerialize_derefs_in_use_blocks

    When nir_rematerialize_derefs_in_use_blocks_impl was first written, I
    attempted to optimize things a bit by not bothering to re-materialize
    the sources of deref instructions figuring that the final caller would
    take care of that.  However, in the case of more complex deref chains
    where the first link or two lives in block A and then another link and
    the load/store_deref intrinsic live in block B it doesn't work.  The
    code in rematerialize_deref_in_block looks at the tail of the chain,
    sees that it's already in block B and skips it, not realizing that part
    of the chain also lives in block A.

    The easy solution here is to just rematerialize deref sources of deref
    instructions as well.  This may potentially lead to a few more deref
    instructions being created by the conditions required for that to
    actually happen are fairly unlikely and, thanks to the caching, it's all
    linear time regardless.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109603
    Fixes: 7d1d1208c2b "nir: Add a small pass to rematerialize derefs
per-block"
    Reviewed-by: Alejandro Piñeiro <apinheiro at igalia.com>

Sorry, but I forgot to add your tested-by before pushing. :-(

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190211/92ad1b49/attachment.html>