Conditional negation elimination in tree-ssa-phiopt.c

[Jeff Law]

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?

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