Re: Anonymous Namespaces

[Chris Lattner <sabre at nondot dot org>]

On 31 Jan 2004, Gabriel Dos Reis wrote:
> | Yes, we use the GCC "3.4" parser, so if it does, we do.  We also don't
> | support export yet.  Regardless, if export was implemented, and an entity
> | was not involved with an exported template, it should still be marked as
> | internal.
>
> You can't have that information availabale at parsing time.  You'd
> need to postpone the tramsutation to link time.  The reason is that,
> the instantiation of exported template can trigger  instantiation in
> chains and those usually implies name lookup  -- which will happen at
> sort of "link time"  when the different translation units are being
> combined together.  The second phase of name critically needs to know

Ok, that makes sense.  When export is an issue, this can certainly be
corrected.  Link time is "soon enough" for LLVM's purposes anyway.

> | It's not just the inliner, it's also the global dead code elimination
> | stuff, and a variety of other optimizations.  For example, the LLVM dead
> | argument eliminator and IP constant prop passes are able to do a lot of
> | nice things to code, but only if it is marked with internal linkage.
>
> But what you need is not "internal linkage" (i.e. declaring  the
> functions or objects as "static"), but the notion of "regarless of the
> actual linkage of this entity, it is referenced only in this
> translation unit and cannot appear somewhere else".

That is exactly what I'm talking about.  I'm very confused here.  In LLVM,
the source-level notion of internal linkage is very different from the
LLVM notion of internal linkage.  I haven't change the C++ front-end at
all in this respect, just the LLVM code that gets generated.  As such,
there is no way that name lookup could be effected.

However, if there are cases where export templates could cause references
to objects in anonymous namespaces from other translation units, the
current LLVM solution will have to be revised.

> | > And if "static" is what you want; just use "static" :-)
> |
> | No.  Static is officially deprecated for that use in C++, not to mention
> | really ugly.
>
> No, no. Read the C++ standard text carefully to see how the
> deprecation text is worded.  But, even then, it has been found that
> that "deprecation" is hasty and in effect menaingless.  It is very
> simple: If you mean static, then use static.  It just can't go away.

I realize this.  Still, you can't make a class static, which is much more
significant anyway.

> I strongly advise against a naive approach to this issue, that would
> not have an understanding of unnamed namespace semantics, C++ name
> lookup rules and exported templates.

Again, I emphasize that the LLVM treatment of this results in
_dramatically_ better code, and has zero semantic implications since
'export' has not been implemented yet.

> | Also, you can't mark a class 'static' (making the member
> | functions, vtables, rtti info, etc all internal).
>
> So what?  What you want is not "static" but a way to say "this thing
> is used only in this translation unit".

_exactly_, which is something that you cannot do without unnamed
namespaces!  For example, if a (nonvirtual) method is only called from one
call site, and its class is in an anonymous namespace, it _should be
inlined_ into that call site, (almost) regardless of how big it is.
There are many other examples of this kind of thing.  How do you achieve
this without anonymous namespaces behaving sanely?

> | That's fine, I just told you how we _implemented it_.
>
> And I just asked you if you implemented the rest of the language.
> Because what it important is not what you implement in isolation, but
> the interaction with the rest of the language.  I just explained you
> how it leads to incorrect translation of conforming codes.

Transforming objects in unnamed namespaces to use LLVM internal linkage
cannot cause any regressions from an unmodified G++ front-end.  In the
future, the addition of export may not make this true, but if so, it can
be dealt with then.  Also, it does not appear to me that export will be
added to g++ anytime in the near future.  I find it ridiculous that you
advocate non-LLVM G++ to generate pessimal code in the meantime.

-Chris

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