[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Anonymous Namespaces
From:       Chris Lattner <sabre () nondot ! org>
Date:       2004-01-31 23:54:47
Message-ID: Pine.LNX.4.44.0401311736010.6637-100000 () nondot ! org
[Download RAW message or body]

On 1 Feb 2004, Gabriel Dos Reis wrote:

> Chris Lattner <sabre@nondot.org> writes:
>
> | Fine, again, _when_ this is an issue, it can be dealt with.
>
> An issue *where*?  A suggestion has been to modify GCC in a way  that
> will make it reject valid programs.  I've pointed out why that
> modification is not correct and suggested alternative.  And I think
> the C++ maintainers understand the issue enough to see the point.

No, the suggestion isn't.  You seem to have a mental block to what I'm
trying to say or something, because it really isn't getting through.  The
modification _is_ correct, you can verify it on the LLVM demo page, and it
will only (possible) change the semantics of programs when export is
implemented.  Again, to emphasize, _the modification is correct_!

> | > | 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.
> | >
> | > But then use a difference terminology if you don't want to confuse
> | > yourself  (or a C++ programmer talking with you).  A C++ programmer knows
> | > what "static" and "internal linkage" means in C++.  If you change
> | > those phrases to mean something different from what they do in a C++
> | > programme source, you better accurately state their meanings.  Using a
> | > different word is far better.
> |
> | I'm sorry, but I'm not confused.  The LLVM notion of internal linkage is
> | the standard one, and corresponds exactly to what the 'static' keyword
> | does at global scope.
>
> There is no distinction between "static" at global scope or at any
> other namespace scope.

I'm sorry, I said 'global scope' but I was thinking C, in C++, I should
have said 'global or namespace scope', as opposed to using static within a
function body.

> And replacing "being declared in an unnamed
> space" with "being declared as static" (with static meaning what is
> means in C and C++), changes the meaning of well-defined programs.

Which I understand and am _not suggesting_.  Please please please read my
emails more carefully, or perhaps with more of an open mind.

> If your notion of internal linkage corresponds to the meaning of
> static, then why did you state:
>
>    In LLVM, the source-level notion of internal linkage is very
>    different from the LLVM notion of internal linkage.
> You've gotten a consistency problem to revolve with yourself.

Unlike the GCC tree representation, LLVM is not intended to follow any
particular source-level language semantics (it is language-independent).
The notion of C/C++ internal linkage happens to match up with the LLVM
notion, but that's no guarantee that it matches up with an _arbitrary_
source language's definition.  Sorry for not being clear, and you're
right, I should have said "may be very different" not "is very different".

> | Unnamed namespaces are NOT the same as internal linkage, but can be
> | transformed to be implemented in terms of it in this  case.
>
> "In this case" meaning precisely?  I've provided sufficient details
> showing in which ways the two notions differ and affect the meaning of
> programs.

In this case, meaning without export.  Again, if you would just TRY YOUR
EXAMPLE in the demo script, or download LLVM and try it out manually, you
will see that it works just FINE!

> | > |  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?
> | >
> | > But an unnamed namespace does not guarantee that an entity defined in it
> | > does not escape!  See the example above.
> |
> | Again, you are confusing notions in the C++ front-end with notions in the
> | optimizer/code generator.
>
> No, I'm confusing nothing.

You certainly leave nothing open for discussion, and are not willing to
approach things with an open mind!  In this case, you happen to be dead
wrong.

> However, you are confuse many distinct things.  (And last time, you
> have a discussion with someone on linkage, you did the same).

Actually, I was not confused in that example either.  One of the
"problems" with LLVM is that it is substantially different than the
"traditional" ways of designing a compiler.  As such, it's notion of
various things are different than what people are accustomed to.  In that
discussion, I was unaware of the difference between "internal weak" and
"external weak" linkage, but that was not confusion. [I may have _caused_
confusion, but I wasn't confused. :) ]

> | > You're free to implement whatever you like in your research compiler.
> |
> | *sigh*, LLVM's goals are for it to be as stable and reliable as a
> | commercial grade compiler, not for it to be "research quality".  Please do
>
> You're confused.  I did not say "research quality".  I said
> "research compiler".

The implication was certainly there, otherwise why would you have included
'research'?

> | not sling insults unless you've _actually tried it out_.  Thanks.  In
>
> It is an insult in your mind only after you managed to read "reaserch
> compiler" as "research quality".

Actually I read your comment exactly as you wrote it and followed the
logical implication.  Coupled with your inflamatory "But of course,
if the only thing you measure is speed and you rank it over
correctness, you may not understand what I'm saying." comment, I don't
think it is an unreasonable conclusion.

> | fact, I think if you did, you would find it optimizes C++ programs
> | _substantially_ better than GCC does, and takes less time to do so.  Your
> | example is just one case, there are many others.
>
> You're confused.  My example is not about how fast is the compiler,
> rather how correct it is.  As I said, if the only thing you measure is
> speed, then you may not get the point.

Again, I am not confused.  You seem to have ignored my statement that "in
LLVM, we consider correctness the #1 concern".  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.

> | > And, I'm not advocating people generate pessimal code.  I'm telling
> | > people that they should teach the inliner about unnamed namespaces
> | > instead of transmuting meanings of well-defined codes.
> |
> | Again, as I said before, the inliner is not the only thing that cares,
> | please read the examples I gave in my previous email.
>
> I did read them and even give a description of what you after (which
> is not static).

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?  Note _again_ that I have said _nothing_ about turning things
in anonymous namespaces into 'static' objects!!

-Chris

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

[prev in list] [next in list] [prev in thread] [next in thread]