public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Martin Jambor <jamborm@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-4686] ipa-cp: Leave removal of unused parameters to IPA-SRA Date: Wed, 14 Dec 2022 00:04:20 +0000 (GMT) [thread overview] Message-ID: <20221214000420.F25CE3872562@sourceware.org> (raw) https://gcc.gnu.org/g:095a13eda2caf6842096a3ab78b2081c50fe8799 commit r13-4686-g095a13eda2caf6842096a3ab78b2081c50fe8799 Author: Martin Jambor <mjambor@suse.cz> Date: Wed Dec 14 00:33:05 2022 +0100 ipa-cp: Leave removal of unused parameters to IPA-SRA Looking at some benchmarks I have noticed many cases when IPA-CP cloned a function for all contexts just because it knew that some parameters were not used at all. Then IPA-SRA looked at the function and cloned it again to split another parameter or two. The latter pass is better equipped to detect when parameters can be altogether removed and so the IPA-CP cloning was for no good reason. This patch simply alters the IPA-CP not to do that in the situations where IPA-SRA can (for nodes which can be made local) with additional dumping requested by Honza. gcc/ChangeLog: 2022-12-13 Martin Jambor <mjambor@suse.cz> * ipa-cp.cc (clone_for_param_removal_p): New function. (estimate_local_effects): Call it before considering cloning just to remove unused parameters. Diff: --- gcc/ipa-cp.cc | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc index cc031ebed0f..300bec54bbd 100644 --- a/gcc/ipa-cp.cc +++ b/gcc/ipa-cp.cc @@ -3700,6 +3700,29 @@ get_max_overall_size (cgraph_node *node) return max_new_size; } +/* Return true if NODE should be cloned just for a parameter removal, possibly + dumping a reason if not. */ + +static bool +clone_for_param_removal_p (cgraph_node *node) +{ + if (!node->can_change_signature) + { + if (dump_file && (dump_flags & TDF_DETAILS)) + fprintf (dump_file, " Not considering cloning to remove parameters, " + "function cannot change signature.\n"); + return false; + } + if (node->can_be_local_p ()) + { + if (dump_file && (dump_flags & TDF_DETAILS)) + fprintf (dump_file, " Not considering cloning to remove parameters, " + "IPA-SRA can do it potentially better.\n"); + return false; + } + return true; +} + /* Iterate over known values of parameters of NODE and estimate the local effects in terms of time and size they have. */ @@ -3722,7 +3745,7 @@ estimate_local_effects (struct cgraph_node *node) &removable_params_cost); int devirt_bonus = devirtualization_time_bonus (node, &avals); if (always_const || devirt_bonus - || (removable_params_cost && node->can_change_signature)) + || (removable_params_cost && clone_for_param_removal_p (node))) { struct caller_statistics stats; ipa_call_estimates estimates;
reply other threads:[~2022-12-14 0:04 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221214000420.F25CE3872562@sourceware.org \ --to=jamborm@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).