<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 5:41 PM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> Previously we disabled compact_virtual_grfs when dumping optimizations.<br>
> The idea here was to make it easier to diff the dumped shader because you<br>
> didn't have a sudden renaming.  However, sometimes a bug is affected by<br>
> compact_virtual_grfs and, when this happens, you want to keep dumping<br>
> instructions with compact_virtual_grfs enabled.  By turning it into an<br>
> optimization pass and dumping it along with the others, we retain the<br>
> ability to diff because you can just diff against the compact_virtual_grf<br>
> output.<br>
<br>
</span>I'd like to understand the bug you encountered.<br></blockquote><div><br></div><div>I really don't think you'd like that.  Those bugs are a real pain.  But yes, I've hit this more times than I can count while working on this stuff.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm kind of concerned that we're going to just run the optimization<br>
loop an extra time for every shader now, since compact_virtual_grfs is<br>
going to set progress = true after the last actual optimization pass<br>
made progress. I guess we could remove that problem by calling<br>
compact_virtual_grfs at the end of the loop, rather than at the<br>
beginning.<br>
</blockquote></div><br></div><div class="gmail_extra">Sure, we can do something to make it not run an extra time.  I'm mostly concerned about not just shutting it off.<br></div></div>