From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28359 invoked by alias); 23 Jul 2012 02:14:22 -0000 Received: (qmail 28350 invoked by uid 22791); 23 Jul 2012 02:14:21 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jul 2012 02:14:08 +0000 From: "amodra at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7 Date: Mon, 23 Jul 2012 02:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: amodra at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-07/txt/msg01763.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Alan Modra changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amodra at gmail dot com --- Comment #2 from Alan Modra 2012-07-23 02:13:53 UTC --- Gultiy as charged. Not splitting the address early loses some opportunities for common subexpression eliminiation. However, splitting the address early a) is inconsistent with the treatment of other powerpc addresses b) can result in incorrect code and/or require hacks (that pessimise scheduling) to prevent incorrect code in other cases, eg. indirect function call sequence. c) can result in silly uses of call-saved regs for the high part of an address calculation around a call or outside of a loop, when it would be far better to just recalculate an address thus freeing the reg for better uses. d) can allow the high/low parts to move in ways that result in the linker disabling optimisation of these sequences for the entire object file (or generating bad code if you have an old linker). eg. another kernel case where the low part moved to a different (hot/cold) section. Overall, I think we get better code by *not* splitting early, particularly for larger functions that run into (c).