From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26076 invoked by alias); 10 May 2014 18:44:36 -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 26064 invoked by uid 89); 10 May 2014 18:44:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f180.google.com Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com) (209.85.212.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 10 May 2014 18:44:34 +0000 Received: by mail-wi0-f180.google.com with SMTP id hi2so2746600wib.13 for ; Sat, 10 May 2014 11:44:31 -0700 (PDT) X-Received: by 10.180.72.179 with SMTP id e19mr8474472wiv.61.1399747471433; Sat, 10 May 2014 11:44:31 -0700 (PDT) Received: from localhost ([2.26.169.52]) by mx.google.com with ESMTPSA id k19sm5937824wic.10.2014.05.10.11.44.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 May 2014 11:44:30 -0700 (PDT) From: Richard Sandiford To: Matthew Fortune Mail-Followup-To: Matthew Fortune ,Vladimir Makarov , Robert Suchanek , "gcc-patches\@gcc.gnu.org" , Kyrill Tkachov , rdsandiford@googlemail.com Cc: Vladimir Makarov , Robert Suchanek , "gcc-patches\@gcc.gnu.org" , Kyrill Tkachov Subject: Re: [RFC][PATCH][MIPS] Patch to enable LRA for MIPS backend 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> <6D39441BF12EF246A7ABCE6654B0235352881A@LEMAIL01.le.imgtec.org> Date: Sat, 10 May 2014 18:44:00 -0000 In-Reply-To: <6D39441BF12EF246A7ABCE6654B0235352881A@LEMAIL01.le.imgtec.org> (Matthew Fortune's message of "Fri, 9 May 2014 22:58:32 +0000") Message-ID: <87vbtd1njm.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-05/txt/msg00676.txt.bz2 Thanks for looking at this. Matthew Fortune writes: >> > 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. >> >> 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). Yeah. > 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. We don't want to create garbage rtl though. The substitution happens in-place, so the routine does temporarily turn the original MEM into the eliminated form. My first reaction after seeing the bug was to pass the operand in as another parameter to valid_address_p. That made the interface a bit ridiculous though, so I didn't post it and reverted the original patch instead. I think a cleaner way of doing it would be to have helper functions that switch in and out of the eliminated form, storing the old form in fields of a new structure (either separate from address_info, or a local inheritance of it). We probably also want to have arrays of address_infos, one for each operand, so that we don't analyse the same address too many times during the same insn. > 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? Yeah, I think so. Memory constraints are different in two main ways: (a) it's obvious from the MEM what the mode and address space of the access actually are. legitimate_address_p is all about the most general address, so in practice no memory constraint should rely on accepting more than legitimate_address_p does. (b) it's useful for one pattern to have several alternatives with different memory constraints (e.g. "ZS", "ZT" and "m" in the 32-bit MIPS move patterns). There isn't really anything special about the first alternative. IMO it'd be good to get rid of this special handling for extra address constraints, but I've no idea how easy that would be. Thanks, Richard