public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.

  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).