[patch] handle new cgraph nodes in ipa-cp pass

[Jan Hubicka]

> Hi,
> 
> On Thu, Apr 01, 2010 at 06:23:54PM -0400, Aldy Hernandez wrote:
> > Hi.
> > 
> > I'm fixing some problems exhibited by TM benchmarks on the
> > transactional-memory branch.
> > 
> > In this particular problem, ipa_lattice_meet() dies because we have no
> > associated parameter/argument info corresponding to a given callee
> > (IPA_NODE_REF).  The callee in question is a transactional clone, which
> > got created by the IPA TM pass (pass_ipa_tm).
> 
> I don't see how ipa_lattice_meet (in trunk) could fail in such a way.
> I assume you mean one of the IPA_NODE_REFs in its caller
> ipcp_propagate_stage (and by dying you mean a vector index error).
> That is indeed very strange because the call to
> ipa_check_create_node_params at the beginning of the function is
> there to avoid exactly these kinds of problems.  How do you create
> the callee?  Specifically, is cgraph_max_uid incremented accordingly? 
> 
> > 
> > The problem is that the summary passes for the all_regular_ipa_passes
> > (which both pass_ipa_cp and pass_ipa_tm belong to) gets run before we
> > run the actual TM pass.  Since the ipa-cp summary pass which initializes
> > IPA_NODE_REF gets called before the TM clones get created in the TM
> > pass, we end up with uninitialized node information.
> > 
> > The ipa-cp pass is actually broken in that it should define 
> > cgraph_add_function_insertion_hook() to handle new cgraph nodes that get
> > created after the summary pass runs, but before the actual pass runs.
> > This seems like a latent bug that is bound to cause problems if any
> > member of all_regular_ipa_passes that runs before ipa-cp creates a new
> > cgraph node (ok, so it's only pass_ipa_whole_program_visibility
> > now).
> 
> Unfortunately, this idea will not work in WHOPR because in WHOPR the
> bodies of the function are not accessible and so IPA-CP cannot analyze
> it.  This is by the way the main reason why the local and global
> analysis is broken up this way.

Well, in general, I hope that WHOPR will allow IPA passes to produce their own
function bodies.  I don't think it is resonable to assume that all IPA passes
will be fully implemented in the strict WHOPR friendly way. I guess we will
necesarily end up mixing both approaches and we will allow special purpose IPA
passes that do very nontrivial transformations that are expected to affect just
small portions of program to actually bring the spefic bodies into WPA driver
and modify them before they get streamed out. (or to invent completely new
functions)

However in this case I guess main problem is where we want TM pass to lie in the
WHOPR queue.  I.e. can it benefit from whole program and are we going to implement
it in WHOPR friendly way? In that case I guess it should be IPA pass, but I guess
current implementation is just touching the function bodies and then it should
be SMALL_IPA pass that will be executed at compilation stage.

Still IPA-CP should behave sanily when some earlier (yet non-existent) IPA pass
decide to invent a new function and do cgraph_add_new_function on it.

Honza