From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74743 invoked by alias); 24 Jun 2015 12:28:59 -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 74722 invoked by uid 89); 24 Jun 2015 12:28:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jun 2015 12:28:56 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-1-MFQ1_BQjSu-rwyvoUFLI9Q-1 Received: from localhost ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2015 13:28:54 +0100 From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@arm.com Cc: GCC Patches Subject: Re: Remove redundant AND from count reduction loop References: <87pp4m8mkp.fsf@e105548-lin.cambridge.arm.com> <87egl1sa2p.fsf@e105548-lin.cambridge.arm.com> <87a8vps6p1.fsf@e105548-lin.cambridge.arm.com> Date: Wed, 24 Jun 2015 12:37:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 24 Jun 2015 12:43:30 +0100") Message-ID: <871th1s322.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-MC-Unique: MFQ1_BQjSu-rwyvoUFLI9Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-06/txt/msg01699.txt.bz2 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 elem= ent >>>> mode. How about: >>>> >>>> (if (VECTOR_INTEGER_TYPE_P (type) >>>> && TYPE_VECTOR_SUBPARTS (type) =3D=3D TYPE_VECTOR_SUBPARTS (TREE= _TYPE (@0)) >>>> && (TYPE_MODE (TREE_TYPE (type)) >>>> =3D=3D 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. >>>>>>> +/* We could instead convert all instances of the vec_cond to negat= e, >>>>>>> + 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_mo= de, > 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). > 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. Thanks, Richard