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