From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55813 invoked by alias); 24 Jun 2015 14:08:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 55795 invoked by uid 89); 24 Jun 2015 14:08:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f173.google.com Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 24 Jun 2015 14:08:07 +0000 Received: by obpn3 with SMTP id n3so27342226obp.0 for ; Wed, 24 Jun 2015 07:08:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.230.75 with SMTP id sw11mr35012124obc.60.1435154885360; Wed, 24 Jun 2015 07:08:05 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Wed, 24 Jun 2015 07:08:05 -0700 (PDT) In-Reply-To: <87twtxqlbq.fsf@e105548-lin.cambridge.arm.com> References: <87pp4m8mkp.fsf@e105548-lin.cambridge.arm.com> <87egl1sa2p.fsf@e105548-lin.cambridge.arm.com> <87a8vps6p1.fsf@e105548-lin.cambridge.arm.com> <871th1s322.fsf@e105548-lin.cambridge.arm.com> <87twtxqlbq.fsf@e105548-lin.cambridge.arm.com> Date: Wed, 24 Jun 2015 14:09:00 -0000 Message-ID: Subject: Re: Remove redundant AND from count reduction loop From: Richard Biener To: Richard Biener , GCC Patches , richard.sandiford@arm.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg01706.txt.bz2 On Wed, Jun 24, 2015 at 3:37 PM, Richard Sandiford 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 >