From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88879 invoked by alias); 17 Jan 2020 09:16:53 -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 88871 invoked by uid 89); 17 Jan 2020 09:16:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-17.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1887, lowest X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jan 2020 09:16:43 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9260E113E; Fri, 17 Jan 2020 01:16:41 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DADCD3F68E; Fri, 17 Jan 2020 01:16:40 -0800 (PST) From: Richard Sandiford To: Wilco Dijkstra Mail-Followup-To: Wilco Dijkstra ,GCC Patches , Richard Earnshaw , Kyrylo Tkachov , richard.sandiford@arm.com Cc: GCC Patches , Richard Earnshaw , Kyrylo Tkachov Subject: Re: [PATCH][AARCH64] Enable compare branch fusion References: Date: Fri, 17 Jan 2020 10:02:00 -0000 In-Reply-To: (Wilco Dijkstra's message of "Tue, 24 Dec 2019 15:57:16 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg01025.txt.bz2 Wilco Dijkstra writes: > Enable the most basic form of compare-branch fusion since various CPUs > support it. This has no measurable effect on cores which don't support > branch fusion, but increases fusion opportunities on cores which do. If you're able to say for the record which cores you tested, then that'd be good. > Bootstrapped on AArch64, OK for commit? > > ChangeLog: > 2019-12-24 Wilco Dijkstra > > * config/aarch64/aarch64.c (generic_tunings): Add branch fusion. > (neoversen1_tunings): Likewise. OK, thanks. I agree there doesn't seem to be an obvious reason why this would pessimise any cores significantly. And it looked from a quick check like all AArch64 cores give these compares the lowest in-use latency (as expected). We can revisit this if anyone finds any counterexamples. Richard > > -- > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c > index a3b18b381e1748f8fe5e522bdec4f7c850821fe8..1c32a3543bec4031cc9b641973101829c77296b5 100644 > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -726,7 +726,7 @@ static const struct tune_params generic_tunings = > SVE_NOT_IMPLEMENTED, /* sve_width */ > 4, /* memmov_cost */ > 2, /* issue_rate */ > - (AARCH64_FUSE_AES_AESMC), /* fusible_ops */ > + (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops */ > "16:12",/* function_align. */ > "4",/* jump_align. */ > "8",/* loop_align. */ > @@ -1130,7 +1130,7 @@ static const struct tune_params neoversen1_tunings = > SVE_NOT_IMPLEMENTED, /* sve_width */ > 4, /* memmov_cost */ > 3, /* issue_rate */ > - AARCH64_FUSE_AES_AESMC, /* fusible_ops */ > + (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops */ > "32:16",/* function_align. */ > "32:16",/* jump_align. */ > "32:16",/* loop_align. */