Re: [C++ PATCH] Implement new "force_static" attribute

[Andrew Pinski <pinskia at gmail dot com>]

On Mon, Jul 1, 2013 at 8:36 AM, David Malcolm <dmalcolm@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