From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14875 invoked by alias); 9 May 2014 22:58:41 -0000 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 Received: (qmail 14859 invoked by uid 89); 9 May 2014 22:58:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 May 2014 22:58:38 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id A87F5696298BA; Fri, 9 May 2014 23:58:30 +0100 (IST) Received: from KLMAIL02.kl.imgtec.org (192.168.5.97) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 9 May 2014 23:58:34 +0100 Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by klmail02.kl.imgtec.org (192.168.5.97) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 9 May 2014 23:58:34 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0174.001; Fri, 9 May 2014 23:58:33 +0100 From: Matthew Fortune To: Richard Sandiford , Vladimir Makarov CC: Robert Suchanek , "gcc-patches@gcc.gnu.org" , Kyrill Tkachov Subject: RE: [RFC][PATCH][MIPS] Patch to enable LRA for MIPS backend Date: Fri, 09 May 2014 22:58:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235352881A@LEMAIL01.le.imgtec.org> References: <87d2h51dm6.fsf@talisman.default> <87d2gqfb7t.fsf@talisman.default> <87ob02jodp.fsf@talisman.default> <87fvl6hnw2.fsf@talisman.default> <5357D588.6000202@redhat.com> <87tx967jnq.fsf@talisman.default> <5368EC5F.3010006@arm.com> <87mweuww37.fsf@talisman.default> In-Reply-To: <87mweuww37.fsf@talisman.default> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00655.txt.bz2 Richard/Vlad, Richard Sandiford writes: > Kyrill Tkachov writes: > > On 03/05/14 20:21, Richard Sandiford wrote: ...snip... > > Hi all, > > This caused some testsuite failures on arm: > > FAIL: gcc.target/arm/vfp-ldmdbd.c scan-assembler fldmdbd > > FAIL: gcc.target/arm/vfp-ldmdbs.c scan-assembler fldmdbs > > FAIL: gcc.target/arm/vfp-ldmiad.c scan-assembler fldmiad > > FAIL: gcc.target/arm/vfp-ldmias.c scan-assembler fldmias > > > > From the vfp-ldmdbd.c test this patch changed the codegen from: > > fldmdbd r5!, {d7} > > > > into > > sub r5, r5, #8 > > fldd d7, [r5] > > > > Which broke the test. >=20 > Sorry for the breakage. I've reverted the patch for now and will send a > fixed version when I have time. The problem appears to lie with the new satisfies_memory_constraint_p which is passing just the address to valid_address_p but the constraint is a memory constraint (which wants the mem to be retained). One option is to re-construct the MEM using the address_info provided to valid_address_p. This has mode, address space and whether it was actually a MEM to start with so there is enough information.=20 Another issue noticed while looking at this: process_address does not seem to make an attempt to check for EXTRA_MEMORY_CONSTRAINT even though it does decompose memory addresses. For the lea address case then the address is checked with valid_address_p. This seems inconsistent, is it intentional? The patch below on top of Richard's addresses both problems and for the fldmdbd test gets the correct output. I haven't done any more testing than that though. I suspect there may be a better approach to achieve the same effect but at least this shows what is wrong with the original change. Regards, Matthew diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c index f59bf55..22bb273 100644 --- a/gcc/lra-constraints.c +++ b/gcc/lra-constraints.c @@ -348,6 +348,9 @@ valid_address_p (struct address_info *ad, const char *c= onstraint =3D 0) rtx saved_index_reg =3D NULL_RTX; rtx *base_term =3D strip_subreg (ad->base_term); rtx *index_term =3D strip_subreg (ad->index_term); +#ifdef EXTRA_CONSTRAINT_STR + rtx orig_op =3D NULL_RTX; +#endif if (base_term !=3D NULL) { saved_base_reg =3D *base_term; @@ -360,9 +363,18 @@ valid_address_p (struct address_info *ad, const char *= constraint =3D 0) saved_index_reg =3D *index_term; lra_eliminate_reg_if_possible (index_term); } +#ifdef EXTRA_CONSTRAINT_STR + if (ad->addr_outer_code =3D=3D MEM) + { + orig_op =3D gen_rtx_MEM (ad->mode, *ad->outer); + MEM_ADDR_SPACE (orig_op) =3D ad->as; + } + else + orig_op =3D *ad->outer; +#endif bool ok_p =3D (constraint #ifdef EXTRA_CONSTRAINT_STR - ? EXTRA_CONSTRAINT_STR (*ad->outer, constraint[0], constraint) + ? EXTRA_CONSTRAINT_STR (orig_op, constraint[0], constraint) #else ? false #endif @@ -2865,7 +2877,8 @@ process_address (int nop, rtx *before, rtx *after) /* Target hooks sometimes reject extra constraint addresses -- use EXTRA_CONSTRAINT_STR for the validation. */ if (constraint[0] !=3D 'p' - && EXTRA_ADDRESS_CONSTRAINT (constraint[0], constraint) + && (EXTRA_ADDRESS_CONSTRAINT (constraint[0], constraint) + || EXTRA_MEMORY_CONSTRAINT (constraint[0], constraint)) && valid_address_p (&ad, constraint)) return change_p; #endif