public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Cgraph alias reorg 8/14 (ipa-cp and ipa-prop update)
Date: Mon, 13 Jun 2011 17:54:00 -0000	[thread overview]
Message-ID: <20110613172707.GA30874@virgil.arch.suse.de> (raw)
In-Reply-To: <20110610145543.GF28776@kam.mff.cuni.cz>

Hi,

On Fri, Jun 10, 2011 at 04:55:43PM +0200, Jan Hubicka wrote:
> Hi,

> this patch updated ipa-cp and ipa-prop for aliases.  It is basically
> easy - we don't analyze nodes represneting aliases and when
> propagating we skip them, like everywhere else.
> 
> There are two problems I noticed.  First we should not propagate
> through calls that are overwritable.  When non-overwritable function
> A has overwritable alias B, we should propagate through calls to A,
> but not throug calls to B.  As discussed on IRC it is probably best
> to zap the jump functions in question at IPA stage (because at
> analysis stage it is not clear at all if the alias will end up
> overwritable with LTO).
> 

OK.  Nevertheless, I'd prefer to do this in context of the new
IPA-CP.  

> Similar problem already exists with code in
> ipa_compute_jump_functions that looks into a callee that might
> change with LTO.

I either don't understand or fail to see how this is different from
the first problem.  We even compute jump functions of indirect edges
precisely because we hope they will be changed later on...


> Index: ipa-cp.c
> ===================================================================
> --- ipa-cp.c	(revision 174905)
> +++ ipa-cp.c	(working copy)
> @@ -818,7 +828,7 @@ ipcp_iterate_stage (void)
>      /* Some lattices have changed from IPA_TOP to IPA_BOTTOM.
>         This change should be propagated.  */
>      {
> -      gcc_assert (n_cloning_candidates);
> +      /*gcc_assert (n_cloning_candidates);*/
>        ipcp_propagate_stage ();
>      }
>    if (dump_file)


I know this assert can be horribly irritating but so far it has been
very useful at spotting all kinds of errors at various places.  (In
fact, you added it :-)

But as I want to get the whole IPA-CP replaced, I don't care all that
much.

Martin

  reply	other threads:[~2011-06-13 17:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-10 15:42 Jan Hubicka
2011-06-13 17:54 ` Martin Jambor [this message]
2011-06-13 19:44   ` Jan Hubicka
2011-06-14 13:19   ` Jan Hubicka
2011-07-12 12:23 ` Maxim Kuvyrkov

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=20110613172707.GA30874@virgil.arch.suse.de \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.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).