Anonymous Namespaces

[Gabriel Dos Reis]

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.

| 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.

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.
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.  So, I would not suggest going with the simpler
approach.  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.

    bool 
    cxx_used_only_in_this_tu (tree_decl *decl)
    {
       return !TREE_PUBLIC (decl)
           || (cxx_no_export && declared_at_unnamed_scope (decl));
    }

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. 

| > | Please please please read my
| > | emails more carefully, or perhaps with more of an open mind.
| >
| > If I was as open minded as you seem to imply, I would have said "Just
| > any bozo" and ignored your message.  Or is it essential for you to
| > believe that you're discussion something with less open minded people?
| 
| I am going to ignore this and the other inflamatory comments and insults
| you use, as they are meaningless in the technical discussion at hand.

you mean "open mind"?  

| > | We are _correct_, as is
| > | GCC.  The only difference is that GCC generates worse code, which I think
| > | is silly.  You never responded to my question about what kind of code GCC
| > | 3.4 generates for your example.
| >
| > For the purpose of comparing apples and oranges?  How do you rewrite
| > the example I gave so that we can compare apples with apples and
| > oranges with oranges?  Because if
| >
| >    Unlike the GCC tree representation, LLVM is not intended to follow any
| >    particular source-level language semantics (it is language-independent).
| >
| > 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. 

| n'th time, the C++ name-lookup functionality is not effected at all
| (and for the third time, you never responded with the code GCC 3.4
| produces on your example!).

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).

| > | And I tried to explain exactly why the transformation is safe, and have
| > | _demonstrated_ that it is for you.  What exactly do you need to be
| > | convinced?
| >
| > I do not want you convince me of anything -- conviction is when religion
| > matters.  If you can't prove your transformation is correct as far as
| > C++ semantics is concerned, let's move on something different.
| 
| 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. 

| >   (2) we're comparing oranges to oranges -- we don't, as you said your
| >       compiler follows no language semantic, whereas g++ ought to
| >       follow language semantics.
| >
| > 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 :-} 

  > 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.

-- Gaby