>>> There is precedence for different >>> expansion paths dependent on optabs (or even rtx cost?). Of course >>> expand_unop doesn't get the original tree ops (expand_expr.c does, >>> where some special-casing using get_gimple_for_expr is). Not sure >>> if expand_unop would get 'cond' in a form where it can recognize >>> the result is either -1 or 0. >> >> It just seems inconsistent to have the optabs machinery try to detect >> this ad-hoc combination opportunity while still leaving the vcond optab >> to handle more arbitrary cases, like (vec_cond (eq x y) 0xbeef 0). >> The vcond optabs would still have the logic needed to produce the >> right code, but we'd be circumventing it and trying to reimplement >> one particular case in a different way. > > That's true. One could also leave it to combine / simplify_rtx and > thus rtx_cost. But that's true of all of the match.pd stuff you add, no?
It's probably true of most match.pd stuff in general though :-) One advantage of match.pd of course is that it works across block boundaries. The difference between the stuff I added and converting vec_cond_expr to negate is that the stuff I added avoids the vec_cond_expr altogether and so ought to be an unequivocal win. Replacing vec_cond_expr with negate just rewrites it into another (arguably more surprising) form. Thanks, Richard
