This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Remove redundant AND from count reduction loop
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at arm dot com
- Date: Wed, 24 Jun 2015 16:08:05 +0200
- Subject: Re: Remove redundant AND from count reduction loop
- Authentication-results: sourceware.org; auth=none
- References: <87pp4m8mkp dot fsf at e105548-lin dot cambridge dot arm dot com> <alpine dot DEB dot 2 dot 20 dot 1506232307180 dot 1715 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0F3YqAjr2+EMf8STUBrVN+bE3aYpC+1nnstSaf2oiaDg at mail dot gmail dot com> <87egl1sa2p dot fsf at e105548-lin dot cambridge dot arm dot com> <CAFiYyc0_JiQSZ=M1NqZAaDgh6kYy_EXtpZp9cd2NJOtTG46ang at mail dot gmail dot com> <87a8vps6p1 dot fsf at e105548-lin dot cambridge dot arm dot com> <CAFiYyc1M4-j8QOWSkowHp8fh5D9ScYACEDPQ0KHH52tEBrP54g at mail dot gmail dot com> <871th1s322 dot fsf at e105548-lin dot cambridge dot arm dot com> <CAFiYyc1Q_NJftYjH49v+konjyiOZw_hzJ6un31R_mizdhk60=w at mail dot gmail dot com> <87twtxqlbq dot fsf at e105548-lin dot cambridge dot arm dot com>
On Wed, Jun 24, 2015 at 3:37 PM, Richard Sandiford
<richard.sandiford@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
>