[PATCH] D19353: [GVN] Replace an inverted comparison with a logical not

[Nick Lewycky via llvm-commits]

On 21 April 2016 at 21:58, Daniel Berlin <dberlin at dberlin.org> wrote:

> 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.
>

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.

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).

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.

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.

Nick

On Thu, Apr 21, 2016 at 11:00 AM, Geoff Berry <gberry at codeaurora.org> wrote:
>
>> gberry added a comment.
>>
>> @reames I believe CodeGenPrepare::SinkCmpExpressions already takes care
>> of this.
>>
>> @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.
>>
>>
>> http://reviews.llvm.org/D19353
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160422/6eda3dae/attachment.html>