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: "Martin Liška" <mliska@suse.cz>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] IPA: do not release body if still needed
Date: Wed, 18 Jan 2023 16:33:20 +0100	[thread overview]
Message-ID: <Y8gRQKG1yiV0YJDb@kam.mff.cuni.cz> (raw)
In-Reply-To: <ri6a62fewqw.fsf@suse.cz>

> The code removing function bodies when the last call graph clone of a
> node is removed is too aggressive when there are nodes up the
> clone_of chain which still need them.  Fixed by expanding the check.
> 
> gcc/ChangeLog:
> 
> 2023-01-18  Martin Jambor  <mjambor@suse.cz>
> 
> 	PR ipa/107944
> 	* cgraph.cc (cgraph_node::remove): Check whether nodes up the
> 	lcone_of chain also do not need the body.
> ---
>  gcc/cgraph.cc | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
> index 5e60c2b73db..5f72ace9b57 100644
> --- a/gcc/cgraph.cc
> +++ b/gcc/cgraph.cc
> @@ -1893,8 +1893,18 @@ cgraph_node::remove (void)
>    else if (clone_of)
>      {
>        clone_of->clones = next_sibling_clone;
> -      if (!clone_of->analyzed && !clone_of->clones && !clones)
> -	clone_of->release_body ();
> +      if (!clones)
> +	{
> +	  bool need_body = false;
> +	  for (cgraph_node *n = clone_of; n; n = n->clone_of)
> +	    if (n->analyzed || n->clones)
> +	      {
> +		need_body = true;
If you want to walk immediate clones and see if any of them is needed, I
wonder why you don't also walk recursively clones of clones?

Original idea was that the clones should be materialized and removed one
by one (or proved unreachable and just removed) and once we remove last
one, we should figure out that body is not needed. For that one does not
not need the walk at all.

How exactly we end up with clones that are not analyzed?

Honza
> +		break;
> +	      }
> +	  if (!need_body)
> +	    clone_of->release_body ();
> +	}
>      }
>    if (next_sibling_clone)
>      next_sibling_clone->prev_sibling_clone = prev_sibling_clone;
> -- 
> 2.39.0
> 

  reply	other threads:[~2023-01-18 15:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01  9:59 Martin Liška
2022-12-09  8:28 ` Martin Liška
2022-12-28  9:20   ` Martin Liška
2023-01-13 16:49 ` Martin Jambor
2023-01-14 21:36 ` Jan Hubicka
2023-01-16 12:31   ` Martin Liška
2023-01-18 14:35     ` Martin Jambor
2023-01-18 15:33       ` Jan Hubicka [this message]
2023-01-19 17:41         ` 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=Y8gRQKG1yiV0YJDb@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mjambor@suse.cz \
    --cc=mliska@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).