On Wed, Jun 24, 2015 at 3:37 PM, Richard Sandiford <richard.sandif...@arm.com> wrote: >>>> 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.
True. Btw, conditional view_convert is now in trunk so you can at least merge both plus:c patterns and both minus patterns. Richard. > Thanks, > Richard >