http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383
--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2011-06-23 17:09:43 UTC --- Hi, sorry for late reply, I was not reading bugs ML very curefully on the GCC gathering... > Honza, the code here is called during expansion of functions. If called at > the > start of a function body, the function is attempting to answer the question: > Can this function be called from anywhere external to this object file? > If called for the expansion of a call then the question is: > Can this function call go to a function external to this object file? > Then, once those questions are answered, further code checks whether function > arguments and return value might be affected by the ABI in force. > > We aren't at all interested in local functions, so I don't think c_node->local > and c_node->can_change_signature are relevant. At least, I don't see that > they > give any more information than cgraph_only_called_directly_p relevant to the > questions call_ABI_of_interest is trying to answer. Hmm, it seems that I managed to invent here quite confusing variants of same test. Ideas for improvements here are certainly welcome. Function is local if a) it is not having address taken b) it is not exported from current unit c) it is locally defined d) it is not extern inline function. e) it is not static ctor or dtor Function is only called directly must match a,b,c and e. I.e. it can be extern inline and this fact is useful for i.e. ipa-cp cloning decisions. This however makes no difference at backend compilation, since all offline copies of extern inlines are eliminated by that time. So when not doing WHOPR both predicates are equivalent at the time you are querying them. Main difference is that locality is defined at WPA time, while cgraph_only_called_directly_p is computed from cgraph. This means that in WHOPR when you have function A only called directly from function B and functoin A goes into partition 1 while, function B into partition 2, cgraph_only_called_directly_p at the ltrans stage will return 0, while the function will still be local. i386 backend use the locality test to alter the ABI and it can consequentely use the register calling conventions cross the ltrans boubdaries (relying that both parallel ltrans compilation will make the same decisions to alter the ABI). I am not sure what call_ABI_of_interest control, really, but I can't imagine it being too different from i386 case. Honza
