This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Implement new "force_static" attribute
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 02 Jul 2013 17:09:43 -0400
- Subject: Re: [C++ PATCH] Implement new "force_static" attribute
- References: <1372693018 dot 1789 dot 110 dot camel at surprise> <CA+=Sn1kSxMEVeVSjwgZpG1FX3CUXY4pHUuBdrzNwA9U43tvCyQ at mail dot gmail dot com>
On Tue, 2013-07-02 at 13:54 -0700, Andrew Pinski wrote:
> On Mon, Jul 1, 2013 at 8:36 AM, David Malcolm <email@example.com> wrote:
> > My plan for removal of global variables in gcc 4.9  calls for several
> > hundred new classes, which will be singletons in a classic monolithic
> > build, but have multiple instances in a shared-library build.
> > In order to avoid the register pressure of passing a redundant "this"
> > pointer around for the classic case, I've been looking at optimizing
> > singletons.
> > I'm attaching an optimization for this: a new "force_static" attribute
> > for the C++ frontend, which when added to a class implicitly adds
> > "static" to all members of said class. This gives a way of avoiding a
> > "this" pointer in the classic build (in stages 2 and 3, once the
> > attribute is recognized), whilst supporting it in a shared-library
> > build, with relatively little boilerplate, preprocessor hackery or
> > syntactic differences.
> > See:
> > http://dmalcolm.fedorapeople.org/gcc/global-state/singletons.html#another-singleton-removal-optimization
> > for more information on how this would be used in GCC itself.
> > With this optimization, the generated machine code *with classes* (with
> > "methods" and "fields") is identical to that with just functions and
> > global variables (apart from the ordering of the functions/"methods"
> > within the .text sections of their respective .o files). 
> > FWIW I've also been looking at another approach:
> > http://dmalcolm.fedorapeople.org/gcc/global-state/singletons.html#a-singleton-removal-optimization
> > which is even lower boilerplate, though I don't have that working yet;
> > it touches the internals of classes and methods much more deeply.
> > BTW, I'm not 100% sold on "force_static" as the name of the attribute;
> > would "implicit_static" be a better name? (the latter is growing on me).
> > Successfully bootstrapped on x86_64-unknown-linux-gnu; all old testcases
> > have the same results as an unpatched build, and all new testcases pass
> > (using r200562 as the baseline).
> I am not a big fan of adding another extension to GCC. Especially one
> where the documentation does not describe all the interactions with
> templates or all of the C++ features.
Right; it doesn't support templates yet, and reviewing my own patch it
looks like the interaction with ctors and dtors could use some work, at
I think a renaming to "implicit_static" may help, so I'll do that in the
Are there other aspects that would need documentation/improvement for
you to be happier with this?
Out of interest, how do you feel about the alternate "singleton"
attribute proposed in my plan:
(I have only a partially-working implementation of this other
> Also Why can't we use some
> preprocess tricks instead of adding this extension?
FWIW I initially did go down the preprocessor route: see
but doing so involves a *lot* of macros: every member function and
variable needs to be marked with "MAYBE_STATIC".
The advantage of the attribute is that the macro markings can be done
per-class rather than per-member, for (waving hands) an
order-of-magnitude fewer macro uses.