Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions

[Jan Hubicka <hubicka at ucw dot cz>]

> 2015-04-03 21:49 GMT+03:00 Jan Hubicka <hubicka@ucw.cz>:
> >> Assembler name of instrumented function is a transparent alias of
> >> original function's name.  Alias chains are not taken into account by
> >> analysis. Thus we see no conflict between instrumented function's name
> >> and a variable name but emit them with the same assembler name. To
> >> detect name conflict I keep original function node alive.
> >
> > Hmm, so lets see if I understand your situation.  You always have transparent alias TA
> > and function F connected by IPA_REF_CHKP and because TA is represented as thunk
> > you also have a fake call from TA to F?
> >
> > I do not understand how you can miss the link these days.  I extended lto-cgraph to
> > always keep thunk and its target in every unit that reffers to thunk. That should
> > solve you problem?  How IPA_REF_CHKP can link get lost?
> 
> References are not streamed out for nodes which are referenced in a
> partition but don't belong to it ('continue' condition in output_refs
> loop).

Yeah, but it already special cases aliases (because we now always preserve IPA_REF_ALIAS link
in the boundary, so I think making IPA_REF_CHKP to be rpeserved should go the same path)
so we can special case the instrumentation thunks too?
> 
> >
> > I suppose we still need to
> >  1) write_symbol and lto-symtab should know that transparent aliases are not real
> >     symbols and ignore them. We have predicate symtab_node::real_symbol_p,
> >     I suppose it should return true.
> >
> >     I think cgraph_merge and varpool_merge in lto-symtab needs to know what to do
> >     when merging two symbols with transparent aliases.
> >  2) At some point we need to populate transparent alias links as discussed in the
> >     other thread.
> >  3) For safety, I guess we want symbol_table::change_decl_assembler_name to either
> >     sanity check there are no trasparent alias links pointing to old assembler
> >     names or update it.
> 
> Wouldn't search for possible referring via transparent aliases nodes
> be too expensive?

Changing of decl_assembler_name is not very common and if we set up the links
only after renaming of statics, i think we are safe. But it would be better to
keep verify it at some point.

I suppose verify_node check that there is no transparent alias link on symbols
were it is not supposed to be and that there is link when it is supposed to be (i.e.
symtab_state is >=EXPANSION and symbol is either weakref on tragets w/o native weakrefs
or instrumentation cone.

Would you please mind adding the test and making sure it triggers when things are
out of sync?

> 
> >  4) I think we want verify_node to check that transparent alias links and chkp points
> >     as intended and only on those symbols where they need to be
> >
> > There is also logic in lto-partition to always insert alias target
> >> > OK, so you have the chkp references that links to instrumented_version.
> >> > You do not stream them for boundary symbols but for some reason they are needed,
> >> > but when you can end up with wrong CHKP link?
> >>
> >> Wrong links may appear when cgraph nodes are merged.
> >
> > I see, I think you really want to fix these at merging time as sugested in 1).
> > In this case even the node->instrumented_version pointer may be out of date and
> > point to a node that lost in merging?
> 
> node->instrumented_version is redirected and never points to lost
> symbol. But during merge we may have situations when
> (node->instrumented_version->instrumented_version != node) because of
> multiple not merged (yet) symbols referencing the same merged target.

OK, which should not be a problem if we stream the links instead of rebuilding them, right?

Honza
> 
> Thanks,
> Ilya
> 
> >
> > Honza
> >>
> >> Thanks
> >> Ilya