public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 3/9] ipa-cp: Leave removal of unused parameters to IPA-SRA
Date: Mon, 12 Dec 2022 22:44:26 +0100	[thread overview]
Message-ID: <Y5egun4eeXO2zArm@kam.mff.cuni.cz> (raw)
In-Reply-To: <ri64ju0imyd.fsf@suse.cz>

> Hi,
> 
> I'm re-posting patches which I have posted at the end of stage 1 but
> which have not passed review yet.
> 
> 8<--------------------------------------------------------------------
> 
> 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).
> 
> Bootstrapped and tested individually when I originally posted it and
> now bootstrapped and LTO-bootstrapped and tested as part of the whole
> series.  OK for master?
> 
> 
> gcc/ChangeLog:
> 
> 2022-11-11  Martin Jambor  <mjambor@suse.cz>
> 
> 	* ipa-cp.cc (estimate_local_effects): Do not clone potentionally local
> 	nodes for all contexts just to remove unused parameters.
> ---
>  gcc/ipa-cp.cc | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> index cc031ebed0f..172ea353c49 100644
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -3722,7 +3722,10 @@ 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
> +	  && node->can_change_signature
> +	  /* If IPA-SRA can do it, it can do it better.  */
> +	  && !node->can_be_local_p ()))
Perhaps we could dump that into dump file (i.e. not cloning because
ipa-sra will do it later).  That could save me from debugging session
in future :)
OK with that change.
Honza
>      {
>        struct caller_statistics stats;
>        ipa_call_estimates estimates;
> -- 
> 2.38.1
> 

  reply	other threads:[~2022-12-12 21:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12 16:52 Martin Jambor
2022-12-12 21:44 ` Jan Hubicka [this message]
2022-12-13 18:34   ` Martin Jambor

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=Y5egun4eeXO2zArm@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mjambor@suse.cz \
    /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: link
Be 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).