Conditional negation elimination in tree-ssa-phiopt.c

[Kyrill Tkachov]

On 18/08/14 10:19, Richard Earnshaw wrote:
> On 14/08/14 09:45, Kyrill Tkachov wrote:
>> On 13/08/14 18:32, Segher Boessenkool wrote:
>>> On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
>>>> The problem with the frankenmonster patterns is that they tend to
>>>> proliferate into the machine description, and before you know where you
>>>> are the back-end is full of them.
>>>>
>>>> Furthermore, they are very sensitive to the greedy first-match nature of
>>>> combine: a better, later, combination is missed because a less good,
>>>> earlier, optimization matched.  If the first insn in the sequence is
>>>> merged into an earlier instruction then you can end up with a junk
>>>> sequence that completely fails to simplify.  That ends up with
>>>> super-frankenmonster patterns to deal with all the subcases and the
>>>> problems grow exponentially from there.
>>> Right.  Of course, combine should be fixed, yadda yadda.
>>>
>>>> I really do think that the best solution would be to try and catch this
>>>> during expand if possible and generate the right pattern from the start;
>>>> then you don't risk combine failing to come to the rescue after several
>>>> intermediate transformations have taken place.
>>> I think ssa-phiopt should simply not do this obfuscation at all.  Without
>>> it, RTL ifcvt picks it up just fine on targets with conditional assignment
>>> instructions.  I agree on targets without expand should do a better job
>>> (also for more generic conditional assignment).
>> That particular transformation was added to tree-ssa-phiopt.c for PR
>> 45685, the problem it was trying to solve was a missed vectorisation
>> opportunity and transforming it made it into straightline code that was
>> more amenable to vectorisation, that's why I'm somewhat reluctant to
>> completely disable it.
>>
>> Hmm... I noticed in the midend we guard some optimisations on
>> HAVE_conditional_move. Maybe we can guard this one on something like
>> !HAVE_conditional_negation ?
>>
> Can't we just guard it on HAVE_conditional_move?  With such an
> instruction expand would then generate
>
> t1 = -a
> r = <cond> ? b : t1
>
> and combine will do the rest.

That was my first idea, but then it disables this transformation for 
x86, for which it was added
specifically to solve PR45685...

Kyrill

> R.
>
>> Kyrill
>>
>>> Instruction selection belongs in RTL land.
>>>
>>>
>>> Segher
>>>
>>