From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7607 invoked by alias); 20 Apr 2011 15:13:13 -0000 Received: (qmail 7596 invoked by uid 22791); 20 Apr 2011 15:13:12 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SARE_OBFU_REAL_SUB X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 20 Apr 2011 15:12:58 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 20 Apr 2011 16:12:54 +0100 Received: from [10.1.67.34] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Apr 2011 16:12:53 +0100 Subject: Re: [patch, ARM] PR48250, rehaul arm_legitimize_reload_address() From: Richard Earnshaw To: Chung-Lin Tang Cc: gcc-patches , richard.sandiford@linaro.org In-Reply-To: <4DAEF677.1030004@codesourcery.com> References: <4D9EBEC8.2020807@codesourcery.com> <4DAEF677.1030004@codesourcery.com> Date: Wed, 20 Apr 2011 15:23:00 -0000 Message-Id: <1303312372.2645.31.camel@e102346-lin.cambridge.arm.com> Mime-Version: 1.0 X-MC-Unique: 111042016125408401 Content-Type: text/plain; charset=WINDOWS-1252 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-04/txt/msg01654.txt.bz2 On Wed, 2011-04-20 at 23:06 +0800, Chung-Lin Tang wrote: > On 2011/4/20 09:24 PM, Richard Sandiford wrote: > > Hi Chung-Lin, > >=20 > > I'm seeing an ICE with this patch, specifically; > >=20 > > Chung-Lin Tang writes: > >> + if (coproc_p) > >> + low =3D SIGN_MAG_LOW_ADDR_BITS (val, 10); > >=20 > > We generate: > >=20 > > Reload 1: reload_out (V4SI) =3D (mem/c:V4SI (plus:SI (plus:SI (reg/f:SI= 11 fp) > > (const_int = -6144 [0xffffffffffffe800])) > > (const_int 1020= [0x3fc])) [43 %sfp+-5024 S16 A64]) > >=20 > > but 1020 isn't a legitimate offset for V4SI: > >=20 > > /* For quad modes, we restrict the constant offset to be slightly less > > than what the instruction format permits. We do this because for > > quad mode moves, we will actually decompose them into two separate > > double-mode reads or writes. INDEX must therefore be a valid > > (double-mode) offset and so should INDEX+8. */ > > if (TARGET_NEON && VALID_NEON_QREG_MODE (mode)) > > return (code =3D=3D CONST_INT > > && INTVAL (index) < 1016 > > && INTVAL (index) > -1024 > > && (INTVAL (index) & 3) =3D=3D 0); > >=20 > > A simple "fix" would be to use 9 instead of 10, but something a little > > more subtle might be preferred :-) > >=20 > > Richard >=20 > Oh dear, for some reason I mistakenly thought that NEON had a quad-word > load/store, sorry :P >=20 > Reducing from 10 to 9 may be a possible solution, if restricted to the > necessary cases. For example: >=20 > -low =3D SIGN_MAG_LOW_ADDR_BITS (val, 10); > +{ > + low =3D SIGN_MAG_LOW_ADDR_BITS (val, 10); > + > + /* NEON quad-word load/stores are made of two double-word accesses, > + so the valid index range is reduced by 8. Treat as 9-bit range if > + we go over it. */ > + if (TARGET_NEON && VALID_NEON_QREG_MODE (mode) && low >=3D 1016) > + low =3D SIGN_MAG_LOW_ADDR_BITS (val, 9); > +} >=20 > To Richard Earnshaw, how do you think of a fix like this? Or should we > just simply return false under this out-of-range case (it should be rare > I hope). >=20 I don't think it matters a great deal. The above is fine. Note, that some targets don't have LDRD either. Do we do the right thing if we're going to fall back to two LDR instructions? R.