From patchwork Tue Oct 15 10:58:30 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 283576 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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id A368E2C00BB for ; Tue, 15 Oct 2013 21:58:47 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=CpcTj7/oOYwYXevmx0REbZyoIDmHEKHOk3sKaEO5FNPDL4 UNuCM2HO/MwQ4NAK0sn4zX1C5xHtx7sl83oIlgY5ZFmUlb1+lWk9FV2E1yVG37jE +ptFI3MQLOyXhHYgW6Wwk6BOezIsYjT7INUK4FOiE4e/6ljjecN2/nlrLTbT4= 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 :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=89e5AIXok0eSFLj2eqHM2cmi34s=; b=aZ95b74/oaTJ3hiuSH1M /xE3J0WLdTB1WTNP26/sI/t0uEZm+uLu5H3xvNIDPX9pbOft4JQ19jjkIWQMUd+9 UNp/fIpMmesEqAG57tmfWqRz36CVcdEqRwhQJOATvVdKwetsIe/yNdNyG3+U+0RX Z+hmggnNE2Vzho6eLnoVXcU= Received: (qmail 31465 invoked by alias); 15 Oct 2013 10:58:41 -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 31453 invoked by uid 89); 15 Oct 2013 10:58:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Oct 2013 10:58:40 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VW2Ki-0003VX-7m from Bernd_Schmidt@mentor.com for gcc-patches@gcc.gnu.org; Tue, 15 Oct 2013 03:58:36 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Oct 2013 03:58:35 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 15 Oct 2013 11:58:33 +0100 Message-ID: <525D1FD6.4030001@codesourcery.com> Date: Tue, 15 Oct 2013 12:58:30 +0200 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130926 Thunderbird/17.0.9 MIME-Version: 1.0 To: GCC Patches , Andrew Jenner Subject: Fix for reloads_unique_chain_p We have a testcase where we have this insn: (insn:HI 53 55 56 2 (set (reg:SI 214 [ D.1303 ]) (mem:SI (plus:SI (mult:SI (reg/v:SI 219 [ p2 ]) (const_int 4 [0x4])) (reg/v/f:SI 218 [ p1 ])) [3 S4 A32])) 163 which produces the following reloads: Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 11 fp) (const_int -16384)) CORE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1) reload_in_reg: (plus:SI (reg/f:SI 11 fp) (const_int -16384)) reload_reg_rtx: (reg:SI 2 r2) Reload 1: reload_in (SI) = (mem/c:SI (plus:SI (plus:SI (reg/f:SI 11 fp) (const_int -16384)) (const_int -536 ))) GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), can't combine reload_in_reg: (reg/v:SI 219 [ p2 ]) reload_reg_rtx: (reg:SI 2 r2) Reload 2: CORE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1) reload_in_reg: (plus:SI (reg/f:SI 11 fp) (const_int -16384)) Reload 3: reload_in (SI) = (mem/c:SI (plus:SI (plus:SI (reg/f:SI 11 fp) (const_int -16384)) (const_int -532))) CORE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), can't combine reload_in_reg: (reg/v/f:SI 218 [ p1 ]) reload_reg_rtx: (reg:SI 1 r1) Of note here is that reload 2 was made and then discarded, and its replacements transferred to the identical reload 0. This means the reload reg from reload 0 is in use by both reloads 1 and 3. This means that the choice of register r2 for reload 1 is wrong: it clobbers r2 which is in use for reload 0. reloads_conflict incorrectly returns false for 0 and 1, and that in turn is because reloads_unique_chain_p returns true for them. In reloads_unique_chain_p we do try to see if the input of r1 is used in any other reload, but this is where we fail: reload_order has arranged for r1==1 and r2==0, so we're testing the wrong reload. Fixed simply by inverting the order if necessary. Bootstrapped and tested on x86_64-linux. Andrew has tested on some arm target with a 4.3-based compiler (I think). Committed (my first successful attempt at git svn dcommit, so I hope I didn't accidentally wipe the tree). There's no testcase for this since the problem is only reproducible with a non-executable complex customer testcase using a patched gcc-4.3. I'm thinking this probably ought to go into 4.8 as well. Bernd commit 6a77b1fca11e2fe9ac20aba2a241ead5a8ebd701 Author: Bernd Schmidt Date: Tue Oct 15 12:16:07 2013 +0200 Fix a miscompilation where a reload reg is reused after it has been clobbered. * reload1.c (reloads_unique_chain_p): Ensure that r1 is the input for r2. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 39ea203..6bf624e 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2013-10-15 Bernd Schmidt + + * reload1.c (reloads_unique_chain_p): Ensure that r1 is the input for + r2. + 2013-10-15 Richard Biener * tree-loop-distribution.c (build_empty_rdg): Inline into diff --git a/gcc/reload1.c b/gcc/reload1.c index bb13bf8..d56c554 100644 --- a/gcc/reload1.c +++ b/gcc/reload1.c @@ -5560,6 +5560,14 @@ reloads_unique_chain_p (int r1, int r2) || reg_mentioned_p (rld[r2].in, rld[r1].in))) return false; + /* The following loop assumes that r1 is the reload that feeds r2. */ + if (r1 > r2) + { + int tmp = r2; + r2 = r1; + r1 = tmp; + } + for (i = 0; i < n_reloads; i ++) /* Look for input reloads that aren't our two */ if (i != r1 && i != r2 && rld[i].in)