Visibility attribute (was: proposed change: weak symbol support for Darwin)

[Matt Austern]

On Monday, October 13, 2003, at 05:46  PM, Alexandre Oliva wrote:

> On Oct 13, 2003, Matt Austern <austern@apple.com> wrote:
>
>> symbols that are public within a dynamic library but that aren't
>> exported beyond the scope of the library boundary.
>
> Like attribute hidden?

I didn't know about the visibility attribute until Alexandre
pointed it out to me.  But now that I've looked at it, I can
answer that question...

Yes, Apple's notion of private extern symbols looks very much
like __attribute__ ((visibility("hidden"))).  It looks so
similar that it would be silly to have two separate
mechanisms.

So I have changed my mind.  I don't want to take one bit in a
decl node for private_extern.  Instead I want to take two bits
and use them for enum symbol_visibility.  Attributes are a
fine user-level syntax, but I don't like using the attribute
mechanism internally for this.

Rationale: anything stored in DECL_ATTRIBUTES is very expensive.
You need to allocate a list node, an attribute node, several
strings.  Looking up an attribute requires several string
comparisons.  (Look at the definition of decl_visibility in
varasm.c: horrible stuff.) All of this is OK if you expect the
thing you're representing to be very rare, but in OS X private
extern function not all that rare.  I'm sure that changing our
private feature to use attributes would hurt compile speed.

So: what I'd like to do is put in a new two-bit visibility field
in struct tree_decl, replace decl_visibility with a DECL_VISIBILIY
macro, and change the parser so that it sets the visibility field
instead of adding an attribute node.

Can anyone convince me that this would be a bad idea?

			--Matt