On 08/13/14 08:57, 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.
Can't argue with that :-)
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.
So the big question in my mind is what form do we want through the
gimple optimizers (COND_EXPR or branchless) and given the chosen form,
can we see a complex-enough expression at expansion time to realize it's
just conditional negation and DTRT based on what capabilities the target
has?
If keeping the COND_EXPR form allows us to make good decisions at
expansion time, I'm not opposed to pulling out those bits from phi-opt
and making the transformation conditional on target attributes during
expansion.
jeff
