This is the mail archive of the gcc@gcc.gnu.org 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 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


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