public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Jan Hubicka" <hubicka@ucw.cz>, "Martin Liška" <mliska@suse.cz>,
	"GCC Patches" <gcc-patches@gcc.gnu.org>
Subject: Re: [RFC, PATCH]: Introduction of callgraph annotation class
Date: Thu, 16 Oct 2014 15:08:00 -0000	[thread overview]
Message-ID: <20141016145730.GC14611@virgil.suse> (raw)
In-Reply-To: <CAFiYyc1iyfpfK=qujDXa_xpp2kQ_j6psEOgxOWT4Y9+NhiAChQ@mail.gmail.com>

Hi,

On Thu, Oct 16, 2014 at 01:44:05PM +0200, Richard Biener wrote:
> On Thu, Oct 16, 2014 at 1:40 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >>
> >> I don't like "generic annotation" facilities at all.  Would it be possible
> >
> > Why?
> 
> Because it's the way to hell if the IL has "magic" things only one
> pass can understand.  It can't ever know if it may invalidate some
> of that data.

But what would be an alternative to summaries?  Putting all, even
pass-special, data into cgraph_node and cgraph_edge?  Because with LTO
we do not have function bodies at our disposal, the summaries that we
keep in annotations are large enough that we certainly do not want to
grow cgraph_node by that much.

Annotations are only intended for IPA passes, intraprocedural ones
should not worry about the magic in them (yeah, IPA-SRA has to, but
the problem is IPA-SRA, not annotations).  Unfortunately, due to the
three stage nature of IPA world, passes will occasionally trip over
each other, but the solution is a clear API so that passes can
"communicate," rather than making every pass understand data of every
other one.  And this patch moves us in that direction.

> 
> Same reason why I dislike the ->aux pointers we have.  (even if they
> are of course convenient)

I don't think aux is a good analogy.  It is used always only very
briefly, while data from annotations is even stored on disk in LTO.

Martin

  parent reply	other threads:[~2014-10-16 15:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15 16:29 Martin Liška
2014-10-16 11:38 ` Richard Biener
2014-10-16 11:42   ` Jan Hubicka
2014-10-16 11:45     ` Richard Biener
2014-10-16 11:52       ` Jan Hubicka
2014-10-16 15:08       ` Martin Jambor [this message]
2014-10-16 11:44   ` Martin Liška
2014-10-16 11:46     ` Richard Biener
2014-10-16 12:05       ` Jan Hubicka
2014-10-16 12:07         ` Martin Liška
2014-10-16 12:11           ` Martin Liška
2014-10-16 14:16 ` Martin Jambor
2014-10-31 14:28   ` Martin Liška

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=20141016145730.GC14611@virgil.suse \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=mliska@suse.cz \
    --cc=richard.guenther@gmail.com \
    /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).