<div dir="ltr"><div><div>For those interested in following along, I've pushed a bunch of stuff to a branch:<br><br><a href="https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/nir-deref-instr">https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/nir-deref-instr</a><br><br></div>I will continue force-pushing that branch as I go.  My current approach to doing things incrementally is to try and do it by type of dereference initially.  It'll be tricky when I start using deref instructions for local variables as that's where most of the passes want to use them.<br><br></div>--Jason<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 1:32 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>All,<br><br></div>Connor and I along with several others have been discussing for a while changing the way NIR dereferences work.  In particular, adding a new nir_deref_instr type where the first one in the chain takes a variable and is followed by a series of instructions which take another deref instruction and do an array or structure dereference on it.<br><br></div>Much of the motivation for this is some of the upcoming SPIR-V stuff where we have more real pointers and deref chains don't really work anymore.  It will also allow for things such as CSE of common derefs which could make analysis easier.  This is similar to what LLVM does and it's working very well for them.<br><br></div>The reason for this e-mail is that this is going to be a flag-day change.  We've been talking about it for a while but this is going to be a major and fairly painful change in the short 
term so no one has actually done it.  It's time we finally just suck it 
up and make it happen.  While we will try to make the change as incrementally and reviewably as possible but there is a real limit as to what is possible here.  My plan is to start cracking away at this on Monday and hopefully have something working for i965/anv by the end of the week or maybe some time the week after.  If anyone has something to say in opposition, please speak up now and not after I've spent a week straight frantically hacking on NIR.<br><br></div><div>I would like everyone to be respectful of the fact that this will be a major change and very painful to rebase.  If you've got outstanding NIR, GLSL, or SPIR-V work that is likely to conflict with this, please try to land it before Monday so that we can avoid rebase conflicts.  If you have interest in reviewing this, please try to be responsive so that we can get it reviewed and landed before it becomes too painful.  I'll try to send out some preview patches as I go so that the data structures themselves can get some review before the rest of the changes have been made.<br></div><div><br>I'm also asking for help from Rob, Bas, and Eric if there are changes needed in any of their drivers.  I suspect the impact on back-end drivers will be low because most of them don't use derefs directly, but it would be good of people were on hand to help catch bugs if nothing else.<br><br></div><div>Thanks,<br><br></div><div>--Jason Ekstrand<br></div><div><br></div></div>
</blockquote></div><br></div>