Conditional negation elimination in tree-ssa-phiopt.c

[Jeff Law]

On 08/18/14 04:33, Kyrill Tkachov wrote:
>
> 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...
And more generally, using HAVE_XXX in the gimple optimizers is generally 
frowned upon.  That's really bring a level of target knowledge into the 
gimple optimizers we don't want.

I wonder if TER could create the res = (rhs & -cond) + cond form as a 
single expression which the gimple->ssa expanders could then emit as a 
series of insns or as a conditional negation on targets that have 
conditional negation.

jeff