From patchwork Wed Sep 12 16:41:24 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Earnshaw X-Patchwork-Id: 183411 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]) by ozlabs.org (Postfix) with SMTP id 744672C008D for ; Thu, 13 Sep 2012 02:41:50 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1348072910; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=NJs43BR f1vuZ3J18I9umzBAG/10=; b=L2y2OC5ymtyZlaCTOEX07EjDSAVXZPyybWvEGhn 3yRW4z19+u06h/fxwFor54jZov/iugRX1lF7uYpcTnp+rU7ma9cBCmQLKGN+vsr4 hbaU7/pRs2iY72il8KKWDQ6IKs11zTbVNiNW9J2YNbGc9NjwPQrFydA2b94NN5Mi UZFA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-MC-Unique:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=q48LIhfDQZaQq9SgJ5ZRQwWiaZL9r1TNOkHVD0/g1gBuvv9GLzNiErIYIoV5f3 MLyC5BEUg8vpOS88r5do+oKctGK04zWwDY27LI7S4i+JtQ5xA621ngcIBsLxRrks hIfZmgt9shuwrPg47JSf3q7lVpuD9rrxHjghKCcVMNGhM=; Received: (qmail 491 invoked by alias); 12 Sep 2012 16:41:45 -0000 Received: (qmail 477 invoked by uid 22791); 12 Sep 2012 16:41:41 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Sep 2012 16:41:28 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 12 Sep 2012 17:41:27 +0100 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Sep 2012 17:41:25 +0100 Message-ID: <5050BB34.5070701@arm.com> Date: Wed, 12 Sep 2012 17:41:24 +0100 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: gcc-patches CC: bernds@codesourcery.com, uweigand@de.ibm.com Subject: [PATCH] proposed fix for PRs target/54516 & rtl-optimization/54540 X-MC-Unique: 112091217412705001 X-IsSubscribed: yes 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 Although the mersenne twister code is new, the build/runtime failures of PRs target/54516 and PR rtl-optimization/54540 can be tracked back to the addition of the variant add %0("=rk"), %1("0"), %2("rk") // size=2 to the thumb2 backend. This is causing reload to try to do clever things when we have a large stack adjustment. Prior to reload we have a sequence of the form: r:SI = sp:SI + (-some_const1) sp:SI = r:SI + (-some_const2) Since there is no thumb2 instruction to directly perform the second operation some reloading is needed. Reload determines that the new variant described above is a viable candidate and sets about trying to create reloads for it. The first thing it does is rearranges the operands to create sp:SI = (-some_const2) + r:SI which now needs precisely one reload. The tie operation forces a reload into sp of the value -some_const2, not realizing that putting random values into SP is potentially very dangerous to the health of your program (or system if you're running at a privileged level). It seems to me that find_dummy_reload is doing an unsafe thing by permitting the use of a register in fixed_regs[] as a reload register -- writing to fixed regs could have unspecified side effects on the machine, so they should only be used in the ways that earlier passes have deemed to be safe, and using them as a temporary is not one of those. So this patch fixes the problem by forcing find_dummy_reload to reject OUT as a valid reload register for IN when OUT overlaps a register mentioned in fixed_regs[]. Bootstrapped on arm-linux-gnueabi with no regressions. No new tests are needed as this fixes the execution failures in the mersenne twister tests. * reload.c (find_dummy_reload): Don't use OUT as a reload reg for IN if it overlaps a fixed register. OK? --- reload.c (revision 191208) +++ reload.c (local) @@ -2036,7 +2036,12 @@ find_dummy_reload (rtx real_in, rtx real However, we only ignore IN in its role as this reload. If the insn uses IN elsewhere and it contains OUT, that counts. We can't be sure it's the "same" operand - so it might not go through this reload. */ + so it might not go through this reload. + + We also need to avoid using OUT if it, or part of it, is a + fixed register. Modifying such registers, even transiently, + may have undefined effects on the machine, such as modifying + the stack pointer. */ saved_rtx = *inloc; *inloc = const0_rtx; @@ -2049,7 +2054,8 @@ find_dummy_reload (rtx real_in, rtx real for (i = 0; i < nwords; i++) if (! TEST_HARD_REG_BIT (reg_class_contents[(int) rclass], - regno + i)) + regno + i) + || fixed_regs[regno + i]) break; if (i == nwords)