Re: Remove redundant AND from count reduction loop

[Richard Sandiford <richard.sandiford@arm.com>]

>>> 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