From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36186 invoked by alias); 9 Oct 2015 16:27:42 -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 36177 invoked by uid 89); 9 Oct 2015 16:27:42 -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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 09 Oct 2015 16:27:41 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id t99GRbHs003000; Fri, 9 Oct 2015 11:27:37 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t99GRauW002998; Fri, 9 Oct 2015 11:27:36 -0500 Date: Fri, 09 Oct 2015 16:27:00 -0000 From: Segher Boessenkool To: Bernd Schmidt Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] bb-reorder: Improve the simple algorithm for -Os (PR67864) Message-ID: <20151009162736.GB32545@gate.crashing.org> References: <56179882.6050501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56179882.6050501@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01002.txt.bz2 On Fri, Oct 09, 2015 at 12:35:46PM +0200, Bernd Schmidt wrote: > On 10/08/2015 06:57 PM, Segher Boessenkool wrote: > >As the PR points out, the "simple" reorder algorithm makes bigger code > >than the STC algorithm did, for -Os, for x86. I now tested it for many > >different targets and it turns out to be worse everywhere. > > That's somewhat disappointing. Wasn't it supposed to improve over it? > What went wrong? I first somehow tested -O2 only. Then when you asked I tested -Os again, but only on powerpc64, and it was 0.1% there. It seems combine.ii is not very representative for this :-/ > >Is this okay for trunk? > > > >2015-10-08 Segher Boessenkool > > > > PR rtl-optimization/67864 > > * gcc/bb-reorder (reorder_basic_blocks_simple): Prefer existing > > fallthrough edges for conditional jumps. Don't sort candidate > > edges if not optimizing for speed. > > Ok. Although it would be nice to understand exactly what causes code > growth and possibly get a real cost estimate rather than such a heuristic. There are two main factors: firstly, you want to have as many fallthroughs as possible (any block that does not end in a fallthrough gets an extra jump insn). I haven't found any purely local heuristic that works better than this patch. Very likely you can do better by looking at bigger parts of the graph (say, identify loops and diamonds). The second thing (which still hurts x86) is that on some targets the "cheap" conditional branches have a very short range. "Simple" has no notion of jump distance at all. Segher