From patchwork Mon Mar 20 11:15:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 740939 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vmtfx55zpz9rxl for ; Mon, 20 Mar 2017 22:16:08 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="EGg+oTEQ"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=Hi9vRNMr6AKIn2XMs J0bcUg7R33IaHhmHsIvv3vtxPehywnYPu7dUbCnjnFKadSGyIc1AYE/o2H4C/LlX /f+46e4kO+QG21m6qLKOKPxa5pFJGdW7P9JtSwdfreTht5exc0aw2D9VZ0796LHe XiblLOOYuhnWVWPDjAA53dP8kw= 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=jLY4KCuCKg2YkJx5LgaMuyt 5ILk=; b=EGg+oTEQbwhOk4Z9m2J9RcfjrnN199LDy2XRByH6oD6DrOfbKJwc4z0 tlIsIdxCZTiu0KR3hKrHImvse2qSWFapQuwV6eg/yBTG8Kr+fxB9vHlwrBYi7TbR Mt5UX6FDZd1V3kLF0/LFj6D0MIFnYYxs6bukiF/stpJzHMji2/e4= Received: (qmail 39149 invoked by alias); 20 Mar 2017 11:15:58 -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 39125 invoked by uid 89); 20 Mar 2017 11:15:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=PLUS 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 ESMTP; Mon, 20 Mar 2017 11:15:55 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 906093DBD0; Mon, 20 Mar 2017 11:15:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 906093DBD0 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 906093DBD0 Received: from tucnak.zalov.cz (ovpn-116-72.ams2.redhat.com [10.36.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 36B2E19E19; Mon, 20 Mar 2017 11:15:56 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v2KBFqHR004944; Mon, 20 Mar 2017 12:15:53 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v2KBFpcD004943; Mon, 20 Mar 2017 12:15:51 +0100 Date: Mon, 20 Mar 2017 12:15:51 +0100 From: Jakub Jelinek To: Uros Bizjak , Bernd Schmidt Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Decrease compile time memory with heavy find_base_{value, term} on i?86/x86_64 (PR rtl-optimization/63191, take 2) Message-ID: <20170320111551.GE11094@tucnak> Reply-To: Jakub Jelinek References: <20170310175329.GX22703@tucnak> <20170310185739.GZ22703@tucnak> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170310185739.GZ22703@tucnak> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes Hi! On Fri, Mar 10, 2017 at 07:57:39PM +0100, Jakub Jelinek wrote: > On Fri, Mar 10, 2017 at 07:52:37PM +0100, Bernd Schmidt wrote: > > On 03/10/2017 06:53 PM, Jakub Jelinek wrote: > > > + > > > +template > > > +static inline rtx > > > +ix86_delegitimize_address_tmpl (rtx x) > > > { > > > > Why is this a template and not a function arg? > > That was just an attempt to ensure that the compiler actually > either inlines it, or doesn't share code between the two versions, so the > base_term_p argument isn't checked at runtime. > But, as I said, I have no problem changing that, i.e. > remove the template line, s/_tmpl/_1/, add , bool base_term_p > and tweak both callers. Here is the other variant of the patch with inline function instead of template. Also bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk (or is the other patch ok)? 2017-03-20 Jakub Jelinek PR rtl-optimization/63191 * config/i386/i386.c (ix86_delegitimize_address): Turn into small wrapper function, moved the whole old content into ... (ix86_delegitimize_address_1): ... this. New inline function. (ix86_find_base_term): Use ix86_delegitimize_address_1 with true as last argument instead of ix86_delegitimize_address. Jakub --- gcc/config/i386/i386.c.jj 2017-03-07 20:04:52.000000000 +0100 +++ gcc/config/i386/i386.c 2017-03-10 14:46:24.351775710 +0100 @@ -17255,10 +17255,16 @@ ix86_delegitimize_tls_address (rtx orig_ has a different PIC label for each routine but the DWARF debugging information is not associated with any particular routine, so it's necessary to remove references to the PIC label from RTL stored by - the DWARF output code. */ + the DWARF output code. -static rtx -ix86_delegitimize_address (rtx x) + This helper is used in the normal ix86_delegitimize_address + entrypoint (e.g. used in the target delegitimization hook) and + in ix86_find_base_term. As compile time memory optimization, we + avoid allocating rtxes that will not change anything on the outcome + of the callers (find_base_value and find_base_term). */ + +static inline rtx +ix86_delegitimize_address_1 (rtx x, bool base_term_p) { rtx orig_x = delegitimize_mem_from_attrs (x); /* addend is NULL or some rtx if x is something+GOTOFF where @@ -17285,6 +17291,10 @@ ix86_delegitimize_address (rtx x) && GET_CODE (XEXP (XEXP (x, 0), 0)) == UNSPEC && XINT (XEXP (XEXP (x, 0), 0), 1) == UNSPEC_PCREL) { + /* find_base_{value,term} only care about MEMs with arg_pointer_rtx + base. A CONST can't be arg_pointer_rtx based. */ + if (base_term_p && MEM_P (orig_x)) + return orig_x; rtx x2 = XVECEXP (XEXP (XEXP (x, 0), 0), 0, 0); x = gen_rtx_PLUS (Pmode, XEXP (XEXP (x, 0), 1), x2); if (MEM_P (orig_x)) @@ -17361,7 +17371,9 @@ ix86_delegitimize_address (rtx x) if (! result) return ix86_delegitimize_tls_address (orig_x); - if (const_addend) + /* For (PLUS something CONST_INT) both find_base_{value,term} just + recurse on the first operand. */ + if (const_addend && !base_term_p) result = gen_rtx_CONST (Pmode, gen_rtx_PLUS (Pmode, result, const_addend)); if (reg_addend) result = gen_rtx_PLUS (Pmode, reg_addend, result); @@ -17399,6 +17411,14 @@ ix86_delegitimize_address (rtx x) return result; } +/* The normal instantiation of the above template. */ + +static rtx +ix86_delegitimize_address (rtx x) +{ + return ix86_delegitimize_address_1 (x, false); +} + /* If X is a machine specific address (i.e. a symbol or label being referenced as a displacement from the GOT implemented using an UNSPEC), then return the base term. Otherwise return X. */ @@ -17424,7 +17444,7 @@ ix86_find_base_term (rtx x) return XVECEXP (term, 0, 0); } - return ix86_delegitimize_address (x); + return ix86_delegitimize_address_1 (x, true); } static void