This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Implement new "force_static" attribute
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: David Malcolm <dmalcolm at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 2 Jul 2013 08:16:26 +0200 (CEST)
- Subject: Re: [C++ PATCH] Implement new "force_static" attribute
- References: <1372693018 dot 1789 dot 110 dot camel at surprise> <CAAiZkiA2ZStotaV_qM=9CYqarQ0-mffHqGGe3aHjNxNNS37nbA at mail dot gmail dot com>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Mon, 1 Jul 2013, Gabriel Dos Reis wrote:
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
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?
In theory, there is always this regular class with data and member
functions that use *this. However, for traditional use (not in a library),
there will be a single global instance of this class. For optimization
purposes, it seems better in that case to make all members (variables and
functions) static to let the compiler use a constant address instead of
passing "this" around.
I don't know exactly how hard it would be for the compiler to do this
optimization without the force_static hint, but it would need to detect
that there is only ever one object created (using -fwhole-program?
visibility?). Or to clone the member functions for each global instance if
it is always clear on which one the function is called (but how do you
determine it is worth it?).
3. Is it that GCC does not know how to optimize objects of empty classes?
GCC indeed isn't very good at that (partially because of the ABI), but I
don't think that's the point here.
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: