This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
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
during expand if possible and generate the right pattern from the
then you don't risk combine failing to come to the rescue after
intermediate transformations have taken place.
I think ssa-phiopt should simply not do this obfuscation at all.
it, RTL ifcvt picks it up just fine on targets with conditional
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]