From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31329 invoked by alias); 18 Oct 2011 13:07:29 -0000 Received: (qmail 31318 invoked by uid 22791); 18 Oct 2011 13:07:28 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,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; Tue, 18 Oct 2011 13:07:09 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 18 Oct 2011 14:07:05 +0100 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Oct 2011 14:07:04 +0100 Message-ID: <4E9D79F7.8030407@arm.com> Date: Tue, 18 Oct 2011 14:26:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Bernd Schmidt CC: GCC Patches , Ramana Radhakrishnan Subject: Re: [ARM] Fix PR49641 References: <4E1610ED.2070108@codesourcery.com> <4E1DA5C4.60806@arm.com> <4E983996.4030908@codesourcery.com> <4E9C2586.7080804@arm.com> <4E9D6EC0.10908@codesourcery.com> <4E9D7155.7050905@arm.com> <4E9D754A.4040804@codesourcery.com> In-Reply-To: <4E9D754A.4040804@codesourcery.com> X-MC-Unique: 111101814070504101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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-10/txt/msg01636.txt.bz2 On 18/10/11 13:47, Bernd Schmidt wrote: > On 10/18/11 14:30, Richard Earnshaw wrote: >> Well, if that's the case why do we need to test for Thumb1 at all? And >> why do we only enable write-back for Thumb1? other ISA variants can >> also do that (I know that Thumb1 requires write-back, but it's >> optionally available for the other ISA flavours). >=20 > We're not trying to generate a writeback sequence with our peepholes. > The problem is that on Thumb, that's the only instruction available, and > we want to make use of it if possible (i.e. register dead afterwards etc.= ). >=20 >=20 > Bernd >=20 OK, I understand now. However, I think it's misleading to talk about thumb1 directly here -- it implies that this doesn't apply in other cases. A better patch, would be (I think) --- gcc/config/arm/arm.c (revision 175906) +++ gcc/config/arm/arm.c (working copy) @@ -9950,7 +9950,9 @@ store_multiple_sequence (rtx *operands, /* If it isn't an integer register, then we can't do this. */ if (unsorted_regs[i] < 0 || (TARGET_THUMB1 && unsorted_regs[i] > LAST_LO_REGNUM) - || (TARGET_THUMB2 && unsorted_regs[i] =3D=3D base_reg) + /* The effects are unpredictable if the base reg is + both updated and stored. */ + || (base_writeback && unsorted_regs[i] =3D=3D base_reg) || (TARGET_THUMB2 && unsorted_regs[i] =3D=3D SP_REGNUM) || unsorted_regs[i] > 14) return 0; and then initialize base_writeback at the entry to the function (I presume that currently we would just set it to be TARGET_THUMB1), perhaps with a comment saying that we don't currently support base_writeback for other ISA variants. R.