From: Richard Guenther <richard.guenther@gmail.com>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH 2/6] Indirect call graph edges
Date: Sat, 13 Feb 2010 18:25:00 -0000 [thread overview]
Message-ID: <84fc9c001002131025j301f6c4eg4872aa27d99f620b@mail.gmail.com> (raw)
In-Reply-To: <84fc9c001002131016s3a81d6a9ib25b73d8064473e5@mail.gmail.com>
On Sat, Feb 13, 2010 at 7:16 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Sat, Feb 13, 2010 at 7:01 PM, Martin Jambor <mjambor@suse.cz> wrote:
>> Hi,
>>
>> this is a re-post of the same patch I already sent here in January.
>> There are only minor differences. I have renamed the flag
>> indirect_call to indirect_inlining_edge and changed its purpose to be
>> exactly that, an edge made direct by indirect inlining (it may go away
>> completely, I currently use it only for asserts in ipa-cp
>> devirtualization) and I have added a few things to cgraph node
>> dumping. Most importantly, I have re-worked streaming so that
>> information for indirect inlining associated with nodes is written to
>> the jump functions section again in order to allow the cgraph stream
>> to remain simple and concise (which means it cannot store trees).
>>
>> The patch adds a new kind of edge to the call graph to represent
>> indirect calls with unknown callees (which we hope we can determine at
>> some stage) and uses them to replace ipa_param_call_notes in
>> ipa-prop.h. My immediate reason to do this is to move all the
>> information there from the notes because I will need them to be in
>> memory managed by the garbage collector (and did not want
>> ipa_node_params to become garbage collected) but in a broader sense
>> this is the right thing to do because it facilitates a more general
>> approach to keep information about such calls (ipa-cp jump functions
>> and the like) that is also consistent with how we do this for direct
>> edges.
>>
>> The data structure layout (a flag and a pointer in struct cgraph_edge
>> to a another special structure) was really chosen by Honza. The
>> subsequent patches add some more stuff to cgraph_indirect_call_info so
>> it won't look this silly for long.
>>
>> I have successfully bootstrapped and tested this beast on x86_84-linux
>> and would like to commit something along these lines when stage1 opens
>> again. Obviously, I welcome any comments.
>
> The cgraph.c file at the top currently contains very brief documentation
> which needs to be updated as it says:
>
> The callgraph at the moment does not represent indirect calls or calls
> from other compilation unit.
>
> Note that I think we should have some more elaborate overall overview
> about the cgraph interface.
Btw, I wonder what the callee node of an indirect edge points to? Should
we have a way to put a cgraph node set there? In IPA mod/ref analysis
it would be useful to know which functions can be reached via an
indirect call - the conservative set should be all functions that had their
address taken (but I believe we lie here for virtual functions).
Pointer analysis could also restrict the callee set like for
void (*p)(void);
if (b)
p = foo;
else
p = bar;
(*p)();
where we know we either call foo or bar. Is there a suitable place to
note this kind of information?
Thanks,
Richard.
next prev parent reply other threads:[~2010-02-13 18:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-13 18:03 [PATCH 0/6] Cgraph changes and various devirtualizations Martin Jambor
2010-02-13 18:03 ` [PATCH 1/6] Clarify edge redirection for inline clones Martin Jambor
2010-02-22 14:23 ` Jan Hubicka
2010-02-13 18:04 ` [PATCH 5/6] Indirect inlining of virtual calls Martin Jambor
2010-02-22 16:49 ` Jan Hubicka
2010-03-10 13:45 ` Martin Jambor
2010-03-10 15:24 ` Jan Hubicka
2010-02-13 18:04 ` [PATCH 3/6] Folding " Martin Jambor
2010-02-13 18:12 ` Richard Guenther
2010-02-13 18:04 ` [PATCH 6/6] Devirtualization in ipa-cp Martin Jambor
2010-02-22 16:37 ` Jan Hubicka
2010-03-11 13:42 ` Martin Jambor
2010-02-13 18:04 ` [PATCH 2/6] Indirect call graph edges Martin Jambor
2010-02-13 18:17 ` Richard Guenther
2010-02-13 18:25 ` Richard Guenther [this message]
2010-03-05 17:06 ` Martin Jambor
2010-02-22 15:52 ` Jan Hubicka
2010-02-22 16:05 ` Richard Guenther
2010-02-22 16:06 ` Jan Hubicka
2010-02-13 18:04 ` [PATCH 4/6] Remove unused ipa_note_param_call.called flag (approved) Martin Jambor
2010-02-13 18:14 ` Richard Guenther
2010-03-05 16:19 ` Martin Jambor
2010-02-22 15:04 ` Jan Hubicka
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=84fc9c001002131025j301f6c4eg4872aa27d99f620b@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=mjambor@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).