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

Re: [trans-mem] ipa pass for tm function cloning


> Here's a simple pass to clone available functions called within a 
> transaction.  The clones are re-written so that all memory accesses are 
> transactionalized.
> 
> I'm pretty well baffled by how complicated the IPA hooks are.  What I 
> have seems to work, but alternately there seems to be 99 other ways I 
> could have achieved the same effect, and I've no real idea if what I 
> have is best.  I've mostly patterned it off the const-pure pass, fwiw.

The issues with synchronizing summaries with changing callgraph on whopr
are indeed bothering me too.  I am all ears for ideas to get it simpler.
The overall plan is to keep function summaries and result of IPA
propagation in local arrays at the time analysis is done (that is at
compile time).  Then use the hooks to keep the summaries up to date as
the callgraph is modified (basically new functions are added/old
removed).
Similarly in execute stage (done at linktime) array of results should be
put on side and using same hooks maintained until final complation time
when the results are applied to function bodies....

I ended up with the hooks registered/deregistered since it seemed easier
to add more complicated stuff here instead of having 100+1 pointers in
pass structure that seemed other alternative not much prettier either.

> +static void
> +ipa_tm_create_version (struct cgraph_node *old_node,
> +		       VEC (cgraph_edge_p, heap) *redirections)
> +{
> +  struct cgraph_node *new_node;
> +  char *tm_name;
> +
> +  new_node = cgraph_function_versioning (old_node, redirections,
> +					 NULL, NULL);
> +
> +  /* ??? Versioning can fail at the discression of the inliner.  */
> +  if (new_node == NULL)
> +    return;

In this case we end up with calls to undefined symbols?
(as per comment in tree_versionable_function_p we should relax
restrictions there.  Variadic functions or setjmp can be clonned, but
function having local labels with address taken and escaping can not I
guess)
> +
> +  /* The generic versioning code forces the function to be visible
> +     only within this translation unit.  This isn't what we want for
> +     functions the programmer marked TM_CALLABLE.  */
> +  if (cgraph_is_master_clone (old_node)
> +      && DECL_IS_TM_CALLABLE (old_node->decl))
> +    {
> +      DECL_EXTERNAL (new_node->decl) = DECL_EXTERNAL (old_node->decl);
> +      TREE_PUBLIC (new_node->decl) = TREE_PUBLIC (old_node->decl);
> +      DECL_WEAK (new_node->decl) = DECL_WEAK (old_node->decl);
> +
> +      new_node->local.externally_visible = old_node->local.externally_visible;
> +      new_node->local.local = old_node->local.local;
> +    }
> +
> +  DECL_IS_TM_CLONE (new_node->decl) = 1;
> +
> +  /* ??? In tree_function_versioning, we futzed with the DECL_NAME.  I'm
> +     not sure why we did this, as it's surely going to destroy any hope
> +     of debugging.  */
> +  DECL_NAME (new_node->decl) = DECL_NAME (old_node->decl);

As far as I can remember, we discussed this while ipa-cp implementation
was merged.  I was not very happy about T.123456 style of naming of the
clones but I was told that debug info should preserve the old names
nicely.  So this seems like tree_function_versioning bug.
Perhaps all the logic for producing weak clones and clones with sane
name should be pushed to the versioning code so the clone names in
general have generic suffixes that tells who has created the clone?

Honza


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