From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 4B7993887023 for ; Wed, 8 Apr 2020 15:13:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4B7993887023 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mjambor@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8C620AAC7; Wed, 8 Apr 2020 15:13:36 +0000 (UTC) From: Martin Jambor To: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Disable aggregate walking in ipa code for optimize_debug In-Reply-To: <20200404095815.GV49582@kam.mff.cuni.cz> References: <20200404095815.GV49582@kam.mff.cuni.cz> User-Agent: Notmuch/0.29.3 (https://notmuchmail.org) Emacs/26.3 (x86_64-suse-linux-gnu) Date: Wed, 08 Apr 2020 17:13:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3055.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 15:13:39 -0000 Hi, On Sat, Apr 04 2020, Jan Hubicka wrote: > Martin, > with optimize_debug or when FRE is disabled propagating aggregates is > useless since we are not going to use them. I think we should also > avoid working hard on the jump functions. > This patch disables it in ipa_load_from_param_agg, but I am not sure if > there are other ways ipa-prop can do the memory walk? if you want to bail out before mem-SSA is walked in order to construct aggregate jump function, I'd do it in determine_known_aggregate_parts. Doing it in ipa_load_from_parm_agg means that the code will still look for stores of constants into aggregates and since this fall, we do not just do it in the BB with the call. Bailing out later in ipa_load_from_parm_agg will however prevent inlining from ever evaluating the predicate. Which brings me to another thing. Note that feeding the results into FRE is not the only use of aggregate jump functions. They can also be used to evaluate inlining predicates and to make calls direct and facilitate indirect inlining. Perhaps we don't want to do neither of those on aggregates at -Og but I do not see them as useless without FRE. Martin > > Bootstrapped/regtested x86_64. Makes sense? > > Honza > > * ipa-fnsummary.c (vrp_will_run_p): Export. > * ipa-fnsummary.h (vrp_will_run_p): Declare. > * ipa-prop.c (ipa_load_from_parm_agg): Use it. > diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c > index d96c8e9b03c..e5f43078c27 100644 > --- a/gcc/ipa-fnsummary.c > +++ b/gcc/ipa-fnsummary.c > @@ -522,7 +522,7 @@ vrp_will_run_p (struct cgraph_node *node) > > /* Similarly about FRE. */ > > -static bool > +bool > fre_will_run_p (struct cgraph_node *node) > { > return (opt_for_fn (node->decl, optimize) > diff --git a/gcc/ipa-fnsummary.h b/gcc/ipa-fnsummary.h > index c6ddc9f3199..f4e1fd0cc86 100644 > --- a/gcc/ipa-fnsummary.h > +++ b/gcc/ipa-fnsummary.h > @@ -371,6 +371,7 @@ void evaluate_properties_for_edge (struct cgraph_edge *e, > void ipa_fnsummary_c_finalize (void); > HOST_WIDE_INT ipa_get_stack_frame_offset (struct cgraph_node *node); > void ipa_remove_from_growth_caches (struct cgraph_edge *edge); > +bool fre_will_run_p (struct cgraph_node *); > > /* Return true if EDGE is a cross module call. */ > > diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c > index 71ac0e104d2..7f654f3aea3 100644 > --- a/gcc/ipa-prop.c > +++ b/gcc/ipa-prop.c > @@ -1091,6 +1091,12 @@ ipa_load_from_parm_agg (struct ipa_func_body_info *fbi, > int index; > HOST_WIDE_INT size; > bool reverse; > + > + /* Do not bother to do analysis when we are not doing propagation of > + aggregates anyway. */ > + if (!fre_will_run_p (cgraph_node::get (current_function_decl))) > + return false; > + > tree base = get_ref_base_and_extent_hwi (op, offset_p, &size, &reverse); > > if (!base)