From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15423 invoked by alias); 20 Jun 2011 03:04:28 -0000 Received: (qmail 15415 invoked by uid 22791); 20 Jun 2011 03:04:27 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 03:04:13 +0000 Received: by vws2 with SMTP id 2so1672123vws.20 for ; Sun, 19 Jun 2011 20:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.38.4 with SMTP id c4mr6282883vdk.232.1308539052158; Sun, 19 Jun 2011 20:04:12 -0700 (PDT) Received: by 10.52.112.161 with HTTP; Sun, 19 Jun 2011 20:04:12 -0700 (PDT) In-Reply-To: <20110619140336.GM21332@bubble.grove.modra.org> References: <20110619140336.GM21332@bubble.grove.modra.org> Date: Mon, 20 Jun 2011 08:06:00 -0000 Message-ID: Subject: Re: powerpc64 large-toc vs. reload From: David Edelsohn To: gcc-patches@gcc.gnu.org, Alan Modra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 X-SW-Source: 2011-06/txt/msg01432.txt.bz2 On Sun, Jun 19, 2011 at 10:03 AM, Alan Modra wrote: > I was alerted to a problem with large toc (-mcmodel=3Dmedium/large) code > a few days ago by warnings emitted during a binutils build. > > dwarf.c: In function 'display_debug_lines_raw': > dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found i= n variable location > dwarf.c:2409:1: note: non-delegitimized UNSPEC UNSPEC_TOCREL (44) found i= n variable location > > On investigating why this was happening, I found that these UNSPECs > were from the high part calculation of a toc-relative address that > didn't get a register. =A0reload allocated the pseudo to a stack slot.. > The stack slot didn't match the tight pattern in delegitimize_address > which is why we have an UNSPEC left in the debug info. =A0The real > problem of course is that reload should never allocate a stack slot > for a simple address calculation that can be rematerialised anywhere > in the function with just one instruction. =A0So after quite a bit of > digging around in reload, I finally figured out that the problem has a > really easy solution. =A0Simply tell reload that those high part address > calculations are constants. =A0Which is true. > > That's what the create_TOC_reference change, and the rs6000.md changes > below do. =A0(I also fix large-toc tls patterns.) =A0The rest of the patch > just adjusts for the changed RTL. > > Bootstrap and regression tests powerpc64-linux in progress. =A0OK to > apply mainline and 4.6 assuming no regressions? > > =A0 =A0 =A0 =A0* config/rs6000/rs6000.c (create_TOC_reference): Wrap high= part > =A0 =A0 =A0 =A0of toc-relative address in CONST. > =A0 =A0 =A0 =A0(rs6000_delegitimize_address): Recognize changed address. > =A0 =A0 =A0 =A0(rs6000_legitimize_reload_address): Likewise. > =A0 =A0 =A0 =A0(rs6000_emit_move): Don't force these constants to memory. > =A0 =A0 =A0 =A0* config/rs6000/rs6000.md (tls_gd, tls_gd_high): Wrap high= part of > =A0 =A0 =A0 =A0toc-relative address in CONST. > =A0 =A0 =A0 =A0(tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high)= : Likewise. > =A0 =A0 =A0 =A0(tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewi= se. Okay. Thanks, David