From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80798 invoked by alias); 24 Aug 2015 16:49:16 -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 80787 invoked by uid 89); 24 Aug 2015 16:49:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 24 Aug 2015 16:49:14 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0A5EE4DB01; Mon, 24 Aug 2015 16:49:13 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7OGnCoC009963; Mon, 24 Aug 2015 12:49:12 -0400 Subject: Re: Use cbranch optabs in ifcvt.c To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: <87oahx6igk.fsf@e105548-lin.cambridge.arm.com> From: Jeff Law Message-ID: <55DB4B08.5010805@redhat.com> Date: Mon, 24 Aug 2015 17:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <87oahx6igk.fsf@e105548-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01445.txt.bz2 On 08/24/2015 05:20 AM, Richard Sandiford wrote: > Similarly to the patch for cmpstr(n), this patch uses the optabs > interface for cbranchcc4 instead of using HAVE_cbranchcc4 directly. > I've cached the result in a pass-local variable (valid only for > the duration of the pass). > > The references to incscc and decscc are dead. The only reference > to them in the documentation is: > > Some machines can also perform @code{and} or @code{plus} operations on > condition code values with less instructions than the corresponding > @samp{cstore@var{mode}4} insn followed by @code{and} or @code{plus}. On those > machines, define the appropriate patterns. Use the names @code{incscc} > and @code{decscc}, respectively, for the patterns which perform > @code{plus} or @code{minus} operations on condition code values. See > @file{rs6000.md} for some examples. The GNU Superoptimizer can be used to > find such instruction sequences on other machines. > > which is in tm.texi rather than md.texi. This seems hopelessly out of > date, not least because rs6000.md has no incscc or decscc patterns. > If the "appropriate patterns" are just combine patterns, perhaps we > should just delete the whole paragraph? I think the whole paragraph should just go away. We don't do anything with those special patterns anymore. The PA still defines them, but they're just combiner patterns in the end. > > Tested on x86_64-linux-gnu. OK to install? > > Thanks, > Richard > > gcc/ > * ifcvt.c (HAVE_incscc, HAVE_decscc, HAVE_cbranchcc4): Delete. > (have_cbranchcc4): New variable. > (cc_in_cond, noce_emit_cmove, noce_get_alt_condition) > (noce_get_condition): Use it instead of HAVE_cbranchcc4. > (if_convert): Initialize have_cbranchcc4. OK. jeff