Conditional negation elimination in tree-ssa-phiopt.c

[Kyrill Tkachov]

On 12/08/14 16:11, Kyrill Tkachov wrote:
> On 12/08/14 15:22, Jeff Law wrote:
>> On 08/12/14 04:31, Kyrill Tkachov wrote:
>>> On 12/08/14 10:39, Richard Biener wrote:
>>>> On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law <law@redhat.com> wrote:
>>>>> On 08/11/14 07:41, Kyrill Tkachov wrote:
>>>>>> I haven't been able to get combine to match the comparison+xor+neg+plus
>>>>>> RTL and it seems like it would be just a workaround to undo the
>>>>>> tree-level transformation.
>>>>> Yea, it'd just be a workaround, but it's probably the easiest way to
>>>>> deal
>>>>> with this problem.  Can you describe in further detail why you
>>>>> weren't able
>>>>> to get this to work?
>>>> Too many instructions to combine I guess.  You might want to add
>>>> intermediate "combine" insn-and-splits.  If that's still a no-go then
>>>> read on.
>> My guess was too many insns as well..  But that's often solvable.
>>
>>>    From the combine dump I can see that it tried to combine up to:
>>> (set (reg/i:SI 0 x0)
>>>        (plus:SI (xor:SI (neg:SI (reg:SI 84 [ D.2565 ]))
>>>                (reg:SI 73 [ D.2564 ]))
>>>            (reg:SI 84 [ D.2565 ])))
>> And did it find a match for this?   What happens if (just for testing
>> purposes), you create a pattern for this?  Does combine then try
>> something even more complex, possibly getting your conditional negation?
> I managed to get combine to recognise this pattern:
> (set (match_operand:GPI 0 "register_operand" "=r")
>           (plus:GPI (xor:GPI (neg:GPI (match_operand:GPI 1
> "register_operand" "r"))
>                              (match_operand:GPI 2 "register_operand" "r"))
>                     (match_dup 1)))
>
> Now what I need is for operand 1 to instead be a cc_reg comparison, but
> when I change operand 1 to this pattern:
>
> (set (match_operand:GPI 0 "register_operand" "=r")
>           (plus:GPI (xor:GPI (neg:GPI (match_operator:GPI 1
> "aarch64_comparison_operator"
>                                   [(match_operand:CC 2 "cc_register" "")
> (const_int 0)]))
>                              (match_operand:GPI 3 "register_operand" "r"))
>                     (match_dup 1)))
>
> This doesn't match. Is there any way to express this in a combineable
> pattern?

argh, Thunderbird enforced the 80 character limit...

The pattern that matched was:
(set (match_operand:GPI 0 "register_operand" "=r")
         (plus:GPI
           (xor:GPI
             (neg:GPI (match_operand:GPI 1 "register_operand" "r"))
             (match_operand:GPI 2 "register_operand" "r"))
           (match_dup 1)))


And the one that failed to combine (with operand 1 substituted for a 
cc_reg comparison) was:

(set (match_operand:GPI 0 "register_operand" "=r")
         (plus:GPI
           (xor:GPI
             (neg:GPI
               (match_operator:GPI 1 "aarch64_comparison_operator"
                 [(match_operand:CC_ZERO 2 "cc_register" "")
                    (const_int 0)]))
               (match_operand:GPI 3 "register_operand" "r"))
           (match_dup 1)))

>
> Thanks,
> Kyrill
>
>
>>> On the other hand, I did manage to write a peephole2 that detected the
>>> sequence of compare+neg+xor+plus and transformed it into the
>>> if_then_else form that our current conditional negation pattern has,
>>> although I'm not sure how flexible this is.
>> Probably not very.  We really should be looking at combine.  In fact, I
>> would argue that we should be looking at combine regardless of whether
>> or not we twiddle expansion as humans or machine generated code could
>> look like this...
>>
>> jeff
>>
>>
>
>