<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 11:03 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 Thu, Feb 19, 2015 at 11:01 PM, Connor Abbott <<a href="mailto:cwabbott0@gmail.com">cwabbott0@gmail.com</a>> wrote:<br>
> I agree with Ken that the regressions are small enough, and it seems<br>
> they're mostly stuff we can prevent by being smarter when doing the<br>
> sel peephole, so it seems like the cleanup that will probably help<br>
> other passes is worth it.<br>
<br>
</span>So, usually we do that as a preparatory patch. Why aren't we doing that here?<br></blockquote><div><br></div><div>Do what in a preparatory patch?  Fix up the sel peephole to be able to handle "if (foo) bar = baz;"?  Sure, I can put that patch together.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
NIR instruction counts is not the metric we care about.<br>
</blockquote></div><br></div><div class="gmail_extra">No, but cleaning things up means that we can do other optimizations better.  Also, in each of those cases, the non-ssa NIR code was better it was just less cleanable by the backend.  We need to work on that, but I don't think it's an indicator of a problem.<br></div><div class="gmail_extra">--Jason<br></div></div>