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: gcc-patches at gcc dot gnu dot org
- Cc: David Malcolm <dmalcolm at redhat dot com>
- Date: Tue, 2 Jul 2013 06:37:22 -0500
- 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> <alpine dot DEB dot 2 dot 10 dot 1307020749460 dot 3919 at laptop-mg dot saclay dot inria dot fr>
On Tue, Jul 2, 2013 at 1:16 AM, Marc Glisse <firstname.lastname@example.org> wrote:
> On Mon, 1 Jul 2013, Gabriel Dos Reis wrote:
>> On Mon, Jul 1, 2013 at 10:36 AM, David Malcolm <email@example.com>
>>> 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.
>> 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"
>From the description, I have the impression you are saying that the class
is essentially a singleton class. Is that right?
Sorry, I am still confused about what the problem is and why we need this
solution -- I read several times David's links but I can't get my head
around the fundamental problem.
> 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
> 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:
> Marc Glisse