Re: [C++] GCC tree linkage types

[Chris Lattner <sabre at nondot dot org>]

> > Better yet, could all of these flags be folded into the DECL_VISIBILITY
> > work?  Perhaps establish some clear semantics for these flags, and get
> > the front-ends to generate the _correct_ flags?
>
> It's not really quite the same things as visibility.  I don't think the
> two
> should be folded together.
>
> But you're right that they're related.  I'm doing the visibility work so
> that handling the weak/comdat/one_only flags will be cleaner.

In LLVM, we currently have the following linkage types:

* internal linkage (ie, static)
* linkonce (globals which merge when linking, but can be deleted from a
  translation unit if they are not used, basically like 'extern inline').
* weak (like linkonce, but cannot be deleted if they are unused in a
  xlation unit)
* external (normal strong, externally visible symbol)

Is there anything wrong with this classification of linkage types?  Is
there something we are missing?  The code I'm using to map GCC linkage
types onto this set is really gross right now, and not nearly as
aggressive as it could be (ie, it maps many things to 'weak' that should
be 'linkonce').

If this seems like a reasonable way to classify linkage types, perhaps GCC
could adopt it, saving one bit of flags.  :)

WRT the visibility issue, the LLVM linker can be provided with a list of
symbols that should be exported from a library: when you link the library
and provide the symbol list, all others globals are marked internal (often
opening a lot of opportunities for IPO at library link time).  Would this
approach mesh well with Apple needs, or do you think that using attributes
is easier/better?

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/