section anchors and weak hidden symbols

[Nathan Sidwell]

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