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 ?
Kyrill
Instruction selection belongs in RTL land.
Segher
