From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14194 invoked by alias); 24 Jun 2015 12:58:45 -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 14182 invoked by uid 89); 24 Jun 2015 12:58:44 -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-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 24 Jun 2015 12:58:42 +0000 Received: by oiyy130 with SMTP id y130so29075198oiy.0 for ; Wed, 24 Jun 2015 05:58:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.85.39 with SMTP id e7mr34194561oez.81.1435150719185; Wed, 24 Jun 2015 05:58:39 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Wed, 24 Jun 2015 05:58:39 -0700 (PDT) In-Reply-To: <871th1s322.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> Date: Wed, 24 Jun 2015 13:11: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/msg01702.txt.bz2 On Wed, Jun 24, 2015 at 2:28 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Wed, Jun 24, 2015 at 1:10 PM, Richard Sandiford >> wrote: >>> Richard Biener writes: >>>>>> I'm fine with using tree_nop_conversion_p for now. >>>>> >>>>> I like the suggestion about checking TYPE_VECTOR_SUBPARTS and the element >>>>> mode. How about: >>>>> >>>>> (if (VECTOR_INTEGER_TYPE_P (type) >>>>> && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)) >>>>> && (TYPE_MODE (TREE_TYPE (type)) >>>>> == TYPE_MODE (TREE_TYPE (TREE_TYPE (@0))))) >>>>> >>>>> (But is it really OK to be adding more mode-based compatibility checks? >>>>> I thought you were hoping to move away from modes in the middle end.) >>>> >>>> The TYPE_MODE check makes the VECTOR_INTEGER_TYPE_P check redundant >>>> (the type of a comparison is always a signed vector integer type). >>> >>> OK, will just use VECTOR_TYPE_P then. >> >> Given we're in a VEC_COND_EXPR that's redundant as well. > > Hmm, but is it really guaranteed in: > > (plus:c @3 (view_convert (vec_cond @0 integer_each_onep@1 integer_zerop@2))) > > that the @3 and the view_convert are also vectors? I thought we allowed > view_converts from vector to non-vector types. Hmm, true. >>>>>>>> +/* We could instead convert all instances of the vec_cond to negate, >>>>>>>> + but that isn't necessarily a win on its own. */ >>>>>> >>>>>> so p ? 1 : 0 -> -p? Why isn't that a win on its own? It looks >>>>>> more compact >>>>>> at least ;) It would also simplify the patterns below. >>>>> >>>>> In the past I've dealt with processors where arithmetic wasn't handled >>>>> as efficiently as logical ops. Seems like an especial risk for 64-bit >>>>> elements, from a quick scan of the i386 scheduling models. >>>> >>>> But then expansion could undo this ... >>> >>> So do the inverse fold and convert (neg (cond)) to (vec_cond cond 1 0)? >>> Is there precendent for doing that kind of thing? >> >> Expanding it as this, yes. Whether there is precedence no idea, but >> surely the expand_unop path could, if there is no optab for neg:vector_mode, >> try expanding as vec_cond .. 1 0. > > Yeah, that part isn't the problem. It's when there is an implementation > of (neg ...) (which I'd hope all real integer vector architectures would > support) but it's not as efficient as the (and ...) that most targets > would use for a (vec_cond ... 0). I would suppose that a single-operand op (neg) is always bettter than a two-operand (and) one. But you of course never know... >> 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? Richard. > Thanks, > Richard >