From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 6F8D2388A030 for ; Sat, 4 Apr 2020 09:58:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F8D2388A030 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 16A59280435; Sat, 4 Apr 2020 11:58:15 +0200 (CEST) Date: Sat, 4 Apr 2020 11:58:15 +0200 From: Jan Hubicka To: gcc-patches@gcc.gnu.org, mjambor@suse.cz Subject: Disable aggregate walking in ipa code for optimize_debug Message-ID: <20200404095815.GV49582@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-42.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Sat, 04 Apr 2020 09:58:17 -0000 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? 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)