> On Aug 14, 2014, at 1:45 AM, Kyrill Tkachov <kyrylo.tkac...@arm.com> 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.
Well if we used COND_EXPR instead for both vectorizer and this case and have Expr.c do the expansion, we solve both issues without any target specific issue on the gimple level :). I might submit a few patches to do something this next year. I have some patches right now but due to internal timing I don't have time to submit them upstream just yet. I developed them for our MIPS product but it carries nicely over to our aarch64 processor too. Thanks, Andrew > > 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 > >
