From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Martin Liška" <mliska@suse.cz>,
"GCC Patches" <gcc-patches@gcc.gnu.org>,
"Martin Jambor" <mjambor@suse.cz>, "Jan Hubicka" <hubicka@ucw.cz>
Subject: Re: [RFC, PATCH]: Introduction of callgraph annotation class
Date: Thu, 16 Oct 2014 11:42:00 -0000 [thread overview]
Message-ID: <20141016114052.GA11618@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAFiYyc12P-DMR=7otSYN+G6DJLK=y+EN7c4sBFZBk1=Lgz9Mzw@mail.gmail.com>
>
> I don't like "generic annotation" facilities at all. Would it be possible
Why?
> to make cgraph UIDs not sparse? (keep a free-list of cgraph nodes
cgraph nodes are already kept "dense" via freelist. However in WPA you usually have a lot
of different nodes prior merging and unreachable code removal and very few afterwards,
the number of nodes grows again with inlining.
Depending on what you want to store for values, I guess either vector or hashtable is
good choice - if you want to keep data that needs to be duplicated per inline clone
you can rely on density. If you want data on few function bodies, you will likely use
hash...
Honza
> with UID < cgraph_max_uid, only really free nodes at the end)
> Using a different data structure than a vector indexed by cgraph UID
> should also be easily possible (a map from UID to data, hash_map <int, T>).
>
> Richard.
>
> > Thank you,
> > Martin
next prev parent reply other threads:[~2014-10-16 11:40 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 [this message]
2014-10-16 11:45 ` Richard Biener
2014-10-16 11:52 ` Jan Hubicka
2014-10-16 15:08 ` Martin Jambor
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=20141016114052.GA11618@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=mjambor@suse.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).