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

[Jeff Law <law at redhat dot com>]

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