From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25579 invoked by alias); 13 Feb 2010 18:25:07 -0000 Received: (qmail 25565 invoked by uid 22791); 13 Feb 2010 18:25:06 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f203.google.com (HELO mail-px0-f203.google.com) (209.85.216.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Feb 2010 18:25:02 +0000 Received: by pxi41 with SMTP id 41so2413741pxi.27 for ; Sat, 13 Feb 2010 10:25:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.213.27 with SMTP id p27mr2004267rvq.176.1266085501257; Sat, 13 Feb 2010 10:25:01 -0800 (PST) In-Reply-To: <84fc9c001002131016s3a81d6a9ib25b73d8064473e5@mail.gmail.com> References: <20100213180136.555197900@alvy.suse.cz> <20100213180157.129177066@alvy.suse.cz> <84fc9c001002131016s3a81d6a9ib25b73d8064473e5@mail.gmail.com> Date: Sat, 13 Feb 2010 18:25:00 -0000 Message-ID: <84fc9c001002131025j301f6c4eg4872aa27d99f620b@mail.gmail.com> Subject: Re: [PATCH 2/6] Indirect call graph edges From: Richard Guenther To: Martin Jambor Cc: GCC Patches , Jan Hubicka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-02/txt/msg00522.txt.bz2 On Sat, Feb 13, 2010 at 7:16 PM, Richard Guenther wrote: > On Sat, Feb 13, 2010 at 7:01 PM, Martin Jambor wrote: >> Hi, >> >> this is a re-post of the same patch I already sent here in January. >> There are only minor differences. =A0I 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. =A0Most 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. =A0My 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. =A0The >> 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. =A0Obviously, I welcome any comments. > > The cgraph.c file at the top currently contains very brief documentation > which needs to be updated as it says: > > =A0 =A0The callgraph at the moment does not represent indirect calls or c= alls > =A0 =A0from 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 =3D foo; else p =3D bar; (*p)(); where we know we either call foo or bar. Is there a suitable place to note this kind of information? Thanks, Richard.