This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Jul 2, 2013 at 1:16 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Mon, 1 Jul 2013, Gabriel Dos Reis wrote:
>
>> On Mon, Jul 1, 2013 at 10: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.
>>
>>
>> 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.

Thanks, Marc!

>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
>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]