On Thu, Aug 28, 2014 at 12:13 AM, Jeff Law <l...@redhat.com> wrote: > 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.
I'd do it the other way around (as the phiopt transform is required for vectorization where vector form may have totally different target capabilities). Like for widening multiplication and FMA do target dependent pattern matching right before RTL expansion (in the widen-mult pass). In this place you don't need to worry about restrictions given by TER (no multiple uses, no loads, no crossing BB boundaries, etc.). Add internal functions for this kind of complex operations (or do a sequence of stmts that expand can handle, breaking multi-use chains to get TER doing its job). And guard all this with optab queries or (yet to implement) can-expand-internal function queries. Richard. > > > jeff
