<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 April 2016 at 21:58, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">My suggestion, given the comments on this thread, would be for someone to make a decision (or build a consensus) on what the canonical form of this kind of thing should look like, and then we just go and make everything do that :P, whether it's the result david has produced, or compare over compare, or whatever.</div></blockquote><div><br></div><div>I think the new form is better because it's less expensive to reverse. We also know that it enables other optimizations to fire which is an indicator that it's a better form, though not conclusive.</div><div><br></div><div>Given a not(%x) you can walk directly to the %x operand and see that it's a compare, then reverse that compare if you really wanted the compare (ie., the compare's operands are live registers due to other uses).</div><div><br></div><div>Given a compare, you'd have to examine the use-list for either its LHS or RHS and look through their other uses until you find a matching but reversed compare (it could be cmp inverse-pred LHS, RHS or it could be cmp swap-pred LHS, RHS) which also dominates the original instruction.</div><div><br></div><div>Teaching the rematerializer about this would be nifty, but given that llvm trunk today can't optimize "a && b || a && b" without this patch I'm inclined to not block it without an example testcase where it causes problems. If we were to spend time improving the backend, I doubt that teaching it to undo this transform would rank highly on the priority list.</div><div><br></div><div>Nick</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(80,0,80)">On Thu, Apr 21, 2016 at 11:00 AM, Geoff Berry </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br></div></div><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">gberry added a comment.<br>
<br>
@reames I believe CodeGenPrepare::SinkCmpExpressions already takes care of this.<br>
<br>
@mcrosier I would guess that any cond branches that have not(c) as their condition would get simplified to use just 'c' and swap the branch targets, so I don't think this would impact the optimizations you mentioned.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D19353" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19353</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>