This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC, PATCH]: Introduction of callgraph annotation class


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]