On Mon, 1 Jul 2013, Gabriel Dos Reis wrote:
On Mon, Jul 1, 2013 at 10: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.
Hi David,
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). [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).
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
--
Marc Glisse
