On Tue, Jul 2, 2013 at 2:09 PM, David Malcolm <dmalc...@redhat.com> wrote: > On Tue, 2013-07-02 at 13:54 -0700, Andrew Pinski wrote: >> On Mon, Jul 1, 2013 at 8:36 AM, David Malcolm <dmalc...@redhat.com> wrote: >> > My plan for removal of global variables in gcc 4.9 [1] 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). [2] >> > >> > 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 > least. (sorry) > > I think a renaming to "implicit_static" may help, so I'll do that in the > next iteration. > > 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: > http://dmalcolm.fedorapeople.org/gcc/global-state/singletons.html#a-singleton-removal-optimization > (I have only a partially-working implementation of this other > attribute). > >> Also Why can't we use some >> preprocess tricks instead of adding this extension? > > FWIW I initially did go down the preprocessor route: see > http://dmalcolm.fedorapeople.org/gcc/global-state/singletons.html#other-ways-to-optimize-singletons > 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.
I think the per-class method is just going to get messy in the sense you have to go back and find the attribute. In the per-member it is easier to find and easier to see. If you want to go this route, I think you should go and propose this to the C++ standard committee first :). Thanks, Andrew > > Thanks > Dave >
