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. Also Why can't we use some preprocess tricks instead of adding this extension? Thanks, Andrew Pinski > > Dave > [1] See http://gcc.gnu.org/ml/gcc/2013-06/msg00215.html > [2] I've written an "asmdiff" tool to help check this: > https://github.com/davidmalcolm/asmdiff
