From patchwork Thu Apr 25 08:04:43 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chung-Ju Wu X-Patchwork-Id: 239424 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 366872C00FD for ; Thu, 25 Apr 2013 18:04:53 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=i7u72y4sBTMwtyDiUj 9WzfVE+OVA1+qmpTqYjz3z6BfXKZRV5WvU6RkLFeC7FH4otA1KX0MwO9hx3QlvcO 0jrl8FgxvepvkPFlAWOWNasY4l+QPPL5XTLOSDFKAGj/qGTGY4EnZkDN/H6kBe1I euydZzJEF98qbPCIsMuyiYq7E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=Ci4rwahLYmSkQdr112RKEiGN 7lw=; b=q9SGbq9OHZIySdelY/24J+dmABsGKWay4Gu2WMiBVhk5ToI/uQJQ0gI0 f9o/Uc4yB8mWqdsoUIht9UZW36KsRvjfY28DsBteGNa/3Ffiq8Y4z0W8P1+U3d52 bYbvQfJulh0ZQ5PJBHUUmh/wMcIlXnpPxfWZP0g/haS1GSueiwk= Received: (qmail 28202 invoked by alias); 25 Apr 2013 08:04:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 28191 invoked by uid 89); 25 Apr 2013 08:04:46 -0000 X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, SPF_PASS, TW_UC, TW_ZJ autolearn=ham version=3.3.1 Received: from mail-da0-f44.google.com (HELO mail-da0-f44.google.com) (209.85.210.44) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 25 Apr 2013 08:04:45 +0000 Received: by mail-da0-f44.google.com with SMTP id z20so1308498dae.3 for ; Thu, 25 Apr 2013 01:04:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.146.232 with SMTP id tf8mr24216280pab.32.1366877083574; Thu, 25 Apr 2013 01:04:43 -0700 (PDT) Received: by 10.68.27.197 with HTTP; Thu, 25 Apr 2013 01:04:43 -0700 (PDT) In-Reply-To: References: <51070AFC.9060200@redhat.com> <51757484.4000608@redhat.com> Date: Thu, 25 Apr 2013 16:04:43 +0800 Message-ID: Subject: Re: [4.9 PATCH, alpha]: Switch alpha to LRA From: Chung-Ju Wu To: Steven Bosscher Cc: Jeff Law , Uros Bizjak , Richard Henderson , "gcc-patches@gcc.gnu.org" , Vladimir Makarov 2013/4/23 Steven Bosscher : > On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote: >> On 04/22/2013 11:17 AM, Uros Bizjak wrote: >>> >>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson >>> wrote: >>>> >>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote: >>>>> >>>>> >>>>> 2013-01-28 Uros Bizjak >>>>> >>>>> * config/alpha/alpha.c (TARGET_LRA_P): New define. >>>>> >>>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu. >>>>> >>>>> OK for 4.9? >>>>> >>>> >>>> Yep. >>> >>> >>> Unfortunately, alphas are much more tied to reload than it was hoped. >>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA >>> without problems, further testing on ev4 and ev5 triggered various >>> problems, one of them is PR57032 [1] that exposed rather unique way of >>> handling aligned/nonaligned memory operands. >>> >>> The patch was reverted. >>> >>> I suspect that fixing older alphas to live with LRA would be quite >>> involved task, and I guess nobody (including me) wants to spend >>> considerable amount of time on a dying architecture. Consequently, >>> this also means that alphas will die together with reload as far as >>> gcc is concerned. >>> >>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032 >> >> Would it make sense to deprecate the older Alpha implementations without >> killing the "modern" ones? > > Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR > target/56858). > > I think it would be a shame to not enable LRA on alpha. It will only > be another excuse to never let reload die, and it will hurt stability > and reliability for Alpha EV6 in the long term as other targets switch > over to LRA. > > Is it possible to add some EV4/EV5 splitters to work around this Alpha > EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO > still better than tying the fate of apha to reload and vice versa.. > > Ciao! > Steven How about using follow constraints? As Uros said, the 'Q' is ignored by LRA. The reason is that the predicate function normal_memory_operand() may change op to a memory location by using resolved_reload_operand(). However, if LRA is enabled, resolve_reload_operand() always returns original reg op because reload_in_progress would never be true, resulting reload loop in this case. So I guess using 'm' constraint instead of 'Q' is able to avoid such abnormal behavior, leaving all the reload jobs to LRA. IMHO that is a simplest solution. At least it passes the case in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032 and successfully build libgcc. Best regards, jasonwucj Index: alpha.c =================================================================== --- alpha.c (revision 198216) +++ alpha.c (working copy) @@ -9871,6 +9871,9 @@ #undef TARGET_LEGITIMATE_ADDRESS_P #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p +#undef TARGET_LRA_P +#define TARGET_LRA_P hook_bool_void_true + #undef TARGET_CONDITIONAL_REGISTER_USAGE #define TARGET_CONDITIONAL_REGISTER_USAGE alpha_conditional_register_usage Index: alpha.md =================================================================== --- alpha.md (revision 198216) +++ alpha.md (working copy) @@ -4073,9 +4073,9 @@ (define_insn "*movdi" [(set (match_operand:DI 0 "nonimmediate_operand" - "=r,r,r,r,r,r,r,r, m, *f,*f, Q, r,*f") + "=r,r,r,r,r,r,r,r, m, *f,*f, m, r,*f") (match_operand:DI 1 "input_operand" - "rJ,K,L,T,s,n,s,m,rJ,*fJ, Q,*f,*f, r"))] + "rJ,K,L,T,s,n,s,m,rJ,*fJ, m,*f,*f, r"))] "register_operand (operands[0], DImode) || reg_or_0_operand (operands[1], DImode)" "@