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


> Jan Hubicka wrote:
> >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).
> 
> That's fair enough.  But a good description somewhere of what sorts
> of things you'd want to generate in an ipa summary (as opposed to
> the kind of data you'd just collect during the execute pass of a
> simple_ipa_pass), as well as a description of all the kinds of hooks
> available would be extremely helpful.

There is overall whopr document; but no documentatio on the current
implementation (yet).  I will try to put something together, wonder
where is the best place to put it to then.
> 
> Because really, ignoring the LTO bits, I can't see that any of the
> existing IPA passes should be anything but simple_ipa_passes.   That
> they aren't merely complicates understanding of what's going on in
> them.

Yep, without LTO there is no much value of IPA passes, except that it
prevents inliner from blowing up peak memory use by too much of
inlining.
> 
> >>+  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)
> 
> Local labels can be duplicated as well.  And it's not like you can
> jump to them from other functions, so escaping labels don't really
> prevent versioning either.

I think the following function can't be resonably clonned:

t(int v)
{ 
  __label__ a,b,c,d,e;
  static void *p[5]={&&a,&&b,&&c,&&d,&&e};
  goto *p[v];
  a:
    return 1;
  b:
    return 2;
  c:
    return 3;
  d:
    return 4;
  e:
    return 5;
}

since all the clones will use same copy of the static array.
> 
> In the end I'm no longer using cgraph_function_versioning because
> it's too focused on versioning for optimization, whereas I'm dealing
> with versioning to fulfill the API.  I have documented external
> assembler names that correspond to functions that have been marked
> with the tm_callable attribute by the user.
> 
> >>+  /* ??? 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?
> 
> That's what I've done.  The DECL_NAME frobbing now lives in
> cgraph_function_versioning, and tree_function_versioning merely
> handles the duplication of the function body.

OK, that seems fine.  We want to have some convenient infrastructure for
clonning as we definitly will end up using it more in near future.

Honza


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