This is the mail archive of the gcc@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]

[PATCH 0/7] Change of call graph interface - cgraph_node function removal


Hi,

I'm sending this email describing the set of patches also to the gcc
mailing list because quite a few people do not follow the gcc-patches
mailing list (where I am sending the individual patches).

The patch set changes the interface of call graph and tries to avoid
lazy call graph node creation wherever easily possible.  Most
importantly, it removes the cgraph_node function.  The vast majority
of call graph users should call cgraph_get_node instead.  This
function does not create a node when it already does not exist but
returns NULL instead.  Users should check for this if that can happen
and might consider using gcc_checking_assert if it cannot but would
result in a failure at some later point (unlike in the previous
version of the patches, there is no cgraph_do_get_node doing this for
you).

In the very few cases where cgraph_get_node is not sufficient for you
because you need to create a node, two new functions for that purpose
are introduced.  cgraph_create_node creates a call graph node for a
declaration and aborts if it already exists.  cgraph_get_create_node
tries to find an existing node for a declaration and creates it if it
does not already exist.

Over the long term we would like to convert some more calls to
cgraph_get_create_node to other accessors (ideally it should be used
only in cgraphbuild.c) so please refrain from adding them unless you
absolutely have to.

I have successfully bootstrapped and tested the patches piecemeal on
x86_64-linux with "all,ada" languages (and enabled checking), I have
bootstrapped and tested the whole set with the same languages on i686,
I have verified that c and c++ testsuite passes on ia64 and a similar
test is in progress on sparc64.  Are the patches OK for trunk?

Thanks,

Martin



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