This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Implement new "force_static" attribute
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 1 Jul 2013 20:41:04 -0500
- Subject: Re: [C++ PATCH] Implement new "force_static" attribute
- References: <1372693018 dot 1789 dot 110 dot camel at surprise>
On Mon, Jul 1, 2013 at 10:36 AM, David Malcolm <firstname.lastname@example.org> 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
> 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.
> for more information on how this would be used in GCC itself.
I am still a little bit confused by this. Help me out:
1. if we don't need to pass `this', why should we ever find
ourselves to writing functions that need one in the first place?
How do shared libraries get into this water?
2. regarding your comment about constexpr. If you think that is useful
you can add it to gnu++03 as __constexpr__ and use it, following
the pattern suggested by RTH.
3. Is it that GCC does not know how to optimize objects of empty classes?
> 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:
> 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).
>  See http://gcc.gnu.org/ml/gcc/2013-06/msg00215.html
>  I've written an "asmdiff" tool to help check this: