Re: Conditional negation elimination in tree-ssa-phiopt.c

[Richard Earnshaw <rearnsha at arm dot com>]

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.

R.

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