From patchwork Tue Apr 23 00:43:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 238703 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 C22DF2C0137 for ; Tue, 23 Apr 2013 10:43:16 +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 :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; q=dns; s=default; b=Ix9v/STyK3dVhieWi sm9lZyR+xGm1yfXD4/adAu+FpT+oOp/4avI4HMD+rZ+sRmWmFI0+EDtWzGBDzw1q hsBqiG4VcQl+iyyTqwRyoEZ6DUQCimnBLmHvJ38R3XirQYR/dhBkGnhxmobp9SHL LzNzUGeBN4QxHcXWFQvFpk6XLo= 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 :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=default; bh=xzjHTXhY/gfcW9FZq0++idE v9Hg=; b=d/g7sIvg47SrzP2pxcQfsUUvtNfagNtmxp70RFt8KYlQ8AzGQY0SjPQ 8jEOGCMDI9uz84CEhWzwVdU2WEcx0N0/n9XsDygJs+xT0rFdKscKxqhHFZK0MjGB z/wR7aa4HFUMuHR4SybOZ6VLoIoUssreiCe4GH2sNdV9TQGgIFPM= Received: (qmail 20563 invoked by alias); 23 Apr 2013 00:43:10 -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 20553 invoked by uid 89); 23 Apr 2013 00:43:09 -0000 X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 23 Apr 2013 00:43:09 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3N0h7hw024267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Apr 2013 20:43:07 -0400 Received: from Mair.local (vpn-48-120.rdu2.redhat.com [10.10.48.120]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r3N0h54r009146; Mon, 22 Apr 2013 20:43:05 -0400 Message-ID: <5175D919.1070704@redhat.com> Date: Mon, 22 Apr 2013 20:43:05 -0400 From: Vladimir Makarov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Meissner , gcc-patches , David Edelsohn , "Bergner, Peter" , aavrunin@redhat.com Subject: Re: RFA: enable LRA for rs6000 [patch for WRF] References: <5166F34C.30901@redhat.com> <20130415224853.GA17643@ibm-tiger.the-meissners.org> <20130416225639.GA16621@ibm-tiger.the-meissners.org> <516EAE5D.4080601@redhat.com> <20130417161042.GA22186@ibm-tiger.the-meissners.org> <51705B25.6020402@redhat.com> <5171B43B.5070400@redhat.com> <20130422043535.GC22536@bubble.grove.modra.org> <51758EF5.8050209@redhat.com> <20130422193149.GA5792@ibm-tiger.the-meissners.org> In-Reply-To: <20130422193149.GA5792@ibm-tiger.the-meissners.org> X-Virus-Found: No On 13-04-22 3:31 PM, Michael Meissner wrote: > On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote: >> On 13-04-22 12:35 AM, Alan Modra wrote: >>> On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote: >>>> I don't understand what this check means and what comments ??? means too. >>> A lo_sum mem is only valid if you know it won't be offset (or that >>> offsetting will never cross a 64k+32k boundary). If the access is >>> smaller than a word then the load or store can be done in one insn. >>> No offset required. If the access is a DFmode *and* you are loading >>> or storing a floating point reg, then the access is also done in one >>> insn. The ??? comment is referring to the fact that you don't know >>> for sure that the DFmode is in a floating point reg. It usually is, >>> but may be in two general purpose regs. Which then need an offset to >>> load/store the second reg. >>> >> Alan, thanks for the explanation. I'll search for another solution. > I'm suspecting secondary_reload needs more tuning for TF/TD modes. > I've fixed dealII crash and commited the patch into the branch as rev. 198169. The dealII crash itself can be cured by treatment of lo_sum for LRA the same way as for reload (please see code checking modes for addressing more one word). But in this case a few tests fail which is cured in LRA itself by trying to load address into pseudo using lo_sum. The patch was successfully bootstrapped (--with-cpu=power7) and tested on GCC testsuite. 2013-04-22 Vladimir Makarov * lra-constraints.c (process_address): Try to put lo_sum into register. * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove lra_in_progress guard for addressing something bigger than word. Index: ChangeLog =================================================================== --- ChangeLog (revision 198101) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2013-04-22 Vladimir Makarov + + * lra-constraints.c (process_address): Try to put lo_sum into + register. + * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove + lra_in_progress guard for addressing something bigger than word. + 2013-04-18 Vladimir Makarov * lra-constraints.c (check_and_process_move): Move code for move Index: config/rs6000/rs6000.c =================================================================== --- config/rs6000/rs6000.c (revision 198101) +++ config/rs6000/rs6000.c (working copy) @@ -5736,7 +5736,7 @@ legitimate_lo_sum_address_p (enum machin return false; if (GET_MODE_NUNITS (mode) != 1) return false; - if (! lra_in_progress && GET_MODE_SIZE (mode) > UNITS_PER_WORD + if (GET_MODE_SIZE (mode) > UNITS_PER_WORD && !(/* ??? Assume floating point reg based on mode? */ TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT && (mode == DFmode || mode == DDmode))) Index: lra-constraints.c =================================================================== --- lra-constraints.c (revision 198101) +++ lra-constraints.c (working copy) @@ -2504,8 +2504,21 @@ process_address (int nop, rtx *before, r *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr); if (! valid_address_p (ad.mode, *ad.outer, ad.as)) { - *ad.inner = addr; - code = -1; + /* Try to put lo_sum into register. */ + insn = emit_insn (gen_rtx_SET + (VOIDmode, new_reg, + gen_rtx_LO_SUM (Pmode, new_reg, addr))); + code = recog_memoized (insn); + if (code >= 0) + { + *ad.inner = new_reg; + if (! valid_address_p (ad.mode, *ad.outer, ad.as)) + { + *ad.inner = addr; + code = -1; + } + } + } } if (code < 0)