On 05/08/13 14:11, Jan Hubicka wrote:
With LTO we play more of similar tricks, by making use of the resolution file.
I.e. for COMMON and EXTERNAL. Does it matter here?
probably. It'd be a missed optimization though, rather than wrong code
emission.
I would preffer the renaming excercise, since the name confused me few times,
too and the other predicate would be useful for IPA code :)
before invoking sed, can we agree on the right names? I propose
* renaming 'binds_local_p' to 'binds_module_p' (and any default implementations
etc likewise). Keeps the semantics of returning true if the symbol is known to
bind in the dynamic object or executable the current object file ends up in.
* a new function or hook 'binds_here_p' (and any default implementations
needed). Returns true if the symbol is known to bind in the object file being
emitted by the current compilation.
'here's not the best name, but sadly 'object' is overloaded and could mean the
object being queried or the object file being emitted. Similarly 'translation
unit' is too restrictive in LTO mode, where multiple TUs are in play. I'm open
to a better name.
Clearly these are related in that binds_here_p returning true implies
binds_module_p being true, and binds_module_p returning false implies
binds_here_p being false.
Because of how gcc's currently structured the implementation of that new hook
would be
if (binds_local_p () && !WEAK ()) return true;
* finally change default_use_anchors_p to use the new hook.
thoughts?
nathan