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

[Andrew Pinski <pinskia at gmail dot com>]

On Tue, Jul 2, 2013 at 2:09 PM, David Malcolm <dmalcolm@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 <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.
>
> 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
>