This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Anonymous Namespaces
- From: Chris Lattner <sabre at nondot dot org>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: gcc at gcc dot gnu dot org, Kevin Atkinson <kevina at gnu dot org>,Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Sat, 31 Jan 2004 13:59:38 -0600 (CST)
- Subject: Re: Anonymous Namespaces
On 31 Jan 2004, Gabriel Dos Reis wrote:
> | 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.
>
> Do you implement the rest of the C++ language (e.g. proper two-phase
> name lookup)? (Note that exported templates also interact with names
> with internal linkage, but granted, we don't have export yet).
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.
> As I explained in another message, if the issue is this particular
> optimization, the right thing to do is teach the programmed inliner
> about unnamed namespace instead of fiddling with the semantics.
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.
Also, adding gigantic random prefixes to program objects amounts to
obfuscation, and have their own problems.
> 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. Also, you can't mark a class 'static' (making the member
functions, vtables, rtti info, etc all internal).
> | This has absolutely no effect on the front-end, we handle it in our
> | version of "expand".
>
> Hmm, are we talking about the C++ front-end? Notice that anything I
> said about has to do with the C++ front-end, not with the middle-end
> or the back-end.
That's fine, I just told you how we _implemented it_. The point is that
it is done, and has a huge positive effect on optimization. Also the LLVM
codebase itself makes extensive usage of anonymous namespaces, so we want
our compiler to be optimized well. :)
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/