Anonymous Namespaces

[Chris Lattner]

On 1 Feb 2004, Gabriel Dos Reis wrote:

> Chris Lattner <sabre@nondot.org> writes:
> | The "right" solution I mention above, would involve the C++ parser setting
> | TREE_PUBLIC to false for entities in anonymous namespaces, and using some
> | other (C++ specific) flag to control name lookup functions.  I am guessing
> | that this is unlikely to fly though, because it would require changing
> | more of the C++ front-end.  As such, I am specifically not suggesting
> | this.
>
> Ahem.

What does 'ahem' mean?

> | If this doesn't make sense, or if I made technical errors in my
> | description, please let me know.  I think it should be clear that either
> | implementation _cannot_ effect name lookup at all, because it does not
> | change the value of any existing flag.
>
> If you assume that your "internal linkage" is not necessarily the same
> as internal linkage in C++, then it makes sense.  If, however, as
> you've claimed, you say they are the same, then it does not fly.  And
> the why can be found if you unwind three or four messages up.

What are you talking about?  LLVM?  LLVM has no bearing on the description
I just gave!

Since you seem to be stuck on LLVM, let me try to clarify what "internal
linkage" means in LLVM.  As described here:
http://llvm.cs.uiuc.edu/docs/LangRef.html#linkage_internal

LLVM 'internal linkage' basically means the same thing as 'static' in
C/C++.  Entities marked internal, in LLVM, cannot participate in linkage
with symbols referenced by other modules.  It's that easy.  Note that LLVM
has no idea what the C++ name-lookup rules are.

In the LLVM C front-end, we map C 'static' functions and variables to be
'internal' in LLVM.  Note that they are _distinct_ ideas, one in the
front-end and one in the "backend" (in this case, LLVM).

Similarly, in the C++ front-end, we map static in the same way, so
'static' and 'internal' basically mean the same thing.  Note that we also,
as discussed in this thread, map entities defined in anonymous namespace
to LLVM 'internal'.  This simply means that entities defined in anonymous
namespaces cannot interact with symbols defined in other modules, it has
___NO EFFECT___ on the C++ front-end at all, including name lookup.  The
optimizer is able to do aggressive transformations to objects with LLVM
internal linkage, so this is a win.

Basically, this is what I was talking about when I suggested seperating
the source-language idea of 'internal linkage' (which can effect name
lookup) from the back-end idea of 'internal linkage' (which can be
different than the source-language idea, as they are with LLVM & C++).

> Whether it is simpler to implement is less obvious.  Ideally,
> optimizations like this should depend on use and potential use, no just
> "declared linkage" because those can vary from languages to languages.

No kidding.

> Whether there are other languages with same intertwining between
> linkage and name lookup (as in C++) that GCC intends to support is
> unclear to me.

I would be shocked if there were.  In any case, they will not use
identical rules to C++.

> So, I would not suggest going with the simpler approach.

That's fine with me, as I mentioned, I prefer the "right" solution myself.

> Teaching the programmed inliner about unnamed namespaces may end up in
> something like your flag, except that it can just be a language hook
> that does not require changing the C++ front-end. E.g.

...

> That hook need not be reserved to the inliner.  I can be used just
> anywhere it makes sense.  No need to overload "internal linkage".
> It may be that for debugging info purposes, the language source notion
> of "internal linkage" would have to be carried into the middle-end and
> the back-end.

This is _exactly_ what I was proposing with the new flag.  If you'd prefer
it as a langhook, be my guest (note that this does require changing the
C++ front-end as well).  At least you're not declaring it to violate
fundemental laws of the C++ standard anymore.

> | > then the comparison is pointless.
> |
> | No it isn't.  In fact, the whole point is that the LLVM _optimizer_ is
> | capable of doing things the GCC _optimizer_ is not.  It does not matter
> | how this information is represented, the point is functionality.  For the
>
> And I've pointed out, that means for C++, you're going to defer this
> optimization and like until pre-link-time when you have information to
> generate something that LLVM-like optimizer could use, because it is
> only at that time you could reliably produce that language-neutral
> optimization.  In effect, that requires some format for translation
> units (other than mere .o) to carry out information to the
> instantiation phase.

I don't really understand what you're saying here.  Are you talking about
an LLVM-style compiler?  In any case, in the absence of export, no fancy
link-time stuff is required.  In LLVM, it is common for almost all objects
to be marked internal at link-time anyway, so the link-time optimizer is
unhindered regardless of what the C++ front-end does.

> With the clear statement of the meaning of your "internal linkage" as in
> this message, I agree.  But then, I would just repeat something I said x
> messages ago: when talking of a C++ program and internal linkage , it is
> unambiguous which it is -- and it is not LLVM :-/ (I suppose this is a
> remake of the other linkage discussion).

Indeed.  I'm glad that we've clarified things.  I will certainly try to be
more specific in the future.

> | I believe that my description above should convince you that the semantics
> | of C++ are preserved, at least in the absence of export (I freely admit
> | that I don't know enough about export to judge how this would interact
> | with it).
>
> Yes, once you don't assume your internal linkage is "static" in C++, I
> fully agree.

Ok.  Sounds good.

> | > So, the question is what are you transforming according to what
> | > semantics and what are you demonstrating?
> |
> | The point is that what LLVM does is irrelevant to this discussion, as GCC
> | is not LLVM.
>
> Oh, really, I would have sweared the contrary :-}

I'm not really sure what you're getting at here.  LLVM has, as one
component, a C/C++ front-end that is build using GCC.  It has many other
components that are not, and LLVM itself is perfectly functional without
any GCC code at all.  If you'd like, you can say that the LLVM project is
a superset of the GCC project, but it does not "use" _all_ of the code or
have _all_ of the features that GCC does, so I'm not sure this is
appropriate either.  In any case LLVM != GCC.

>   > Yes. The second phase of two-phase name lookup ignores functions with
>   > internal linkages.  Also, entities with internal linkage cannot be
>   > used as template arguments.
>
>   With the LLVM G++ front-end, all entities declared in an anonymous
>   namespace are emitted with internal linkage, including any related RTTI
>   info, vtables, etc.

I don't understand what you're saying here.

-Chris

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