From patchwork Tue Sep 8 03:47:44 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 515268 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id DC1A514016A for ; Tue, 8 Sep 2015 13:48:02 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=mnUeZMXJ; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=cI0kvWV1DsyKjkY/g2FGlAtEI1H1i4Iio2nhbvPg4jbqncwp93 Mw0wDPVa33wRpJ4URU4WXzwRgxEU0biSHuBwSnVvlFV/B9k80p2edmwHJIXzOhtF GW/HkPQuUlBEzE61HMZk9/M6OyoEzOS7gdjnuYr2/kWHBCVD57LrjgDDk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=MlPQcYHSnoJHFMddrWvOYl9Jzrk=; b=mnUeZMXJBq/vPC7jSpk9 JBI51GZvAkstxB85iw9qHH5rsnKDqA7+DSWeE6VuSJKyh6LMqUys6XdLyEocuFut dLOro7MRXyPlYq2Vwixr1NOMAOuUU3g5tumg17AD5VtlxUnNlOGdfkS7BnyLyabW fkNet9HkZ1wXwA0Qsrzc4d8= Received: (qmail 89954 invoked by alias); 8 Sep 2015 03:47:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 89945 invoked by uid 89); 8 Sep 2015 03:47:53 -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, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 08 Sep 2015 03:47:52 +0000 Received: by padhy16 with SMTP id hy16so109444058pad.1 for ; Mon, 07 Sep 2015 20:47:50 -0700 (PDT) X-Received: by 10.68.196.202 with SMTP id io10mr52465703pbc.141.1441684070487; Mon, 07 Sep 2015 20:47:50 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-163-67.gqzg1.fli.bigpond.net.au. [58.160.163.67]) by smtp.gmail.com with ESMTPSA id gx11sm1396132pbd.82.2015.09.07.20.47.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 20:47:49 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id A4F5FEA00EF; Tue, 8 Sep 2015 13:17:44 +0930 (ACST) Date: Tue, 8 Sep 2015 13:17:44 +0930 From: Alan Modra To: gcc-patches@gcc.gnu.org Cc: David Edelsohn Subject: [RS6000] Fix PowerPC ICE due to secondary_reload ignoring reload replacements Message-ID: <20150908034744.GA13304@bubble.grove.modra.org> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67378 analysis I show the reason for this PR is that insns emitted by secondary reload patterns are being generated without taking into account other reloads that may have occurred. We run into this problem when an insn has a pseudo that doesn't get a hard reg, and the pseudo is used in a way that requires a secondary reload. In this case the secondary reload is needed due to gcc generating a 64-bit gpr load from memory insn with an address offset not a multiple of 4. Bootstrapped and regression tested powerpc64-linux. OK to apply? gcc-5 and gcc-4.9 branches too? I haven't included a testcase in this patch, because the testcase in the PR is quite horrible, and testcases triggering reload misbehaviour tend to be unreliable. By unreliable, I mean a small change anywhere in the compiler can result in the testcase passing even if this bug was reintroduced at some future date. The testcase doesn't fail on gcc-5, even though I'm fairly sure the same bug lurks there.. PR target/67378 * config/rs6000/rs6000.c (rs6000_secondary_reload_gpr): Find reload replacement for PRE_MODIFY address reg. diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index cfd5675..51046d4 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -18199,8 +18199,21 @@ rs6000_secondary_reload_gpr (rtx reg, rtx mem, rtx scratch, bool store_p) if (GET_CODE (addr) == PRE_MODIFY) { + gcc_assert (REG_P (XEXP (addr, 0)) + && GET_CODE (XEXP (addr, 1)) == PLUS + && XEXP (XEXP (addr, 1), 0) == XEXP (addr, 0)); scratch_or_premodify = XEXP (addr, 0); - gcc_assert (REG_P (scratch_or_premodify)); + if (!HARD_REGISTER_P (scratch_or_premodify)) + /* If we have a pseudo here then reload will have arranged + to have it replaced, but only in the original insn. + Use the replacement here too. */ + scratch_or_premodify = find_replacement (&XEXP (addr, 0)); + + /* RTL emitted by rs6000_secondary_reload_gpr uses RTL + expressions from the original insn, without unsharing them. + Any RTL that points into the original insn will of course + have register replacements applied. That is why we don't + need to look for replacements under the PLUS. */ addr = XEXP (addr, 1); } gcc_assert (GET_CODE (addr) == PLUS || GET_CODE (addr) == LO_SUM);