This is the mail archive of the 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: [tree-profiling] fix some side corners of finalization machinery

While I agree with you at the top level. There is a problem with perspective with these definitions.

{function body|name} {visible | invisible}

with respect to the bodies, the idea is visible from inside the compilation unit.
with respect to the names, the idea is visible from outside the compilation unit.

There is also something that I have not bitten off yet. That is what about the standard libraries. Apparently I can know a lot more about the function bodies of some of these without actually having the body around. There are currently some attributes that are processed (i.e. hidden) for a lot of the math library where I can know that the only side effect that this function could have is that errno is modified. I say hidden because it looks like the compiler has a flag that either marks these functions as pure if errno is not set but if the flag goes the other way provides no information about about the function.

I could do a lot better with these functions if I could see the unvarnished flags because from my point of view all statics can live across the call with the possible exception of errno (depending on the flag).


Jan Hubicka wrote:

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

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?



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