From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9558 invoked by alias); 12 May 2015 22:36:42 -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 9546 invoked by uid 89); 12 May 2015 22:36:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 12 May 2015 22:36:41 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4CMaTrW020998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 12 May 2015 18:36:30 -0400 Received: from localhost.localdomain (ovpn-113-21.phx2.redhat.com [10.3.113.21]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4CMaT9T009489; Tue, 12 May 2015 18:36:29 -0400 Message-ID: <5552806C.6040602@redhat.com> Date: Tue, 12 May 2015 22:54:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: James Bowman , Joseph Myers CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, FT32] initial support References: , , , ,<5540658A.9040608@redhat.com> ,<55511270.70708@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01171.txt.bz2 On 05/12/2015 04:17 PM, James Bowman wrote: >> On 05/08/2015 06:04 PM, James Bowman wrote: >>> >>>> Are you using LRA or reload? The former is definitely preferred and for >>>> a simple target like this, I'd expect the transition to be very easy. >>> >>> I'm using reload. Attempting to naively switch on LRA resulted in >>> internal compiler error: Max. number of generated reload insns per insn is achieved (90) >>> so I would be very interested in a pointer an LRA clues.D Thanks. >> Vladimir Makarov would be the best contact point. I'm a bit surprised >> you ran into this issue given the simplicity of the port. >> >> I'd minimize the testcase, then enable debugging dumps, then look at the >> insn that's causing LRA to loop. If Vlad helps, he's probably going to >> want that minimized testcase as well, so it's time well spent. >> > > It seems that with whenever a function's frame is bigger than 512 bytes, > LRA loops. Likely this causes a problem because there is no actual > instruction for subtracting constants more than 512. However, there is a > "link" pattern that allows this. It is puzzling. Is the subtraction part of the prologue/epilogue or some address calculation elsewhere in the code? What do you do prior to reload for subtracting a large constant? Presumably you copy it into a register then do a reg-reg subtraction? You might start by setting a breakpoint in lra_emit_add and see what kinds of insns its emits. If you're getting in there, I'd hazard a guess that it's generating reload insns that themselves need reloads. > > Do you think it would be easier to make the submission as is, then debug > the LRA issues from that point? If so, I have attached the current patch set. Not sure yet :-) We really want to get away from the reload path and one way is to stop accepting ports that use it. We've done similar things in the past with other deprecated codepaths. It really depends on the complexity of getting LRA working for the target and given what I saw when looking at the port, I don't believe it should be much work. > > Thanks. > > -- > James Bowman > FTDI Open Source Liaison >