Re: [tree-profiling] fix some side corners of finalization machinery

[Jan Hubicka <hubicka at ucw dot cz>]

> > If I remove my checks for the flags and add your patch, I still cannot 
> > compile the java library.    Here is the patch that will get you there.
> > 
> > just start clean and type make and let it go.  I will crash at the right 
> > spot.
> 
> You run into somewhat sick (surprising?:) GCC extension here.  There is
> function called "restore" that is static but it is not defined in the
> file in a way GCC can parse.  Instead it's ASM name is set by hand and
> the body is provided via toplevel ASM statement.
> 
> I would say that only sane way to deal with this function is to believe
> that it is "external" even tought it is really defined locally.  I guess
> we might simply make external to for IPA purposes to be !finalized - ie
> if the body is not known, pretend that it is external even in such a
> side corners where TREE_PUBLIC is not set.
> 
> Also note that you need to deal with third class of functions -
> functions whose body is known but whose might be overwriten by linker.
> This include all default visibility functions in PIC libraries.  C
> frontend uses test:
>   /* Don't auto-inline anything that might not be bound within
>      this unit of translation.  */
>   if (!DECL_DECLARED_INLINE_P (fn) && !targetm.binds_local_p (fn))
> 
> While C++ frontend uses:
>   /* Don't auto-inline anything that might not be bound within
>      this unit of translation.
>      Exclude comdat functions from this rule.  While they can be bound
>      to the other unit, they all must be the same.  This is especially
>      important so templates can inline.  */
>   if (!DECL_DECLARED_INLINE_P (fn) && !(*targetm.binds_local_p) (fn)
>       && !DECL_COMDAT (fn))
> 
> While in pure/const function discovery there is more conservative
> check to targetm.binds_local_p.  I guess we have obvious need for one
> extra language hook (I wonder if in C++ the one-definition-rule don't
> say that we might conclude that all the functions are known, Mark, any
> comments?)
> 
> Changing the external flag definition itself won't make abort go away
> but I guess couple of places in your ipa code will help...

We probably ought to find way of funny sounding flags here.
What about having function (or variable) in the cgraph_node specifying
visibility of the function for IPA optimizers that might have something
like KNOWN/OVERWRITTABLE/UNKNOWN values instead of current flags having
meanings "function body is known", "function is external", "function is
eternal and its body is unknown" and new "function is known but might be
overwriten by other unit arbitrarily".

Would that suit your needs comfortably?  I wonder what the name should
be.  "body_visibility" comes to mind but we want symmetric value for
global variables too....
Also I guess it is better to organize these thinks as predicates on
nodes instead of having explicit flags in nodes as we are getting into
flag explossion already.  What do you think?

Honza
> 
> Honza