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, 2013-07-02 at 08:16 +0200, Marc Glisse 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.

Exactly (assuming that by "constant address" you're referring to the
address of each member variable, when it becomes static).

> 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?).

It may work when the class is confined to a single TU, but in the
general case such an approach would also require building the compiler
with LTO to get back to the old performance, which might be a
significant imposition (e.g. needing plenty of RAM, for starters).

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

Right, the objects would only be empty when marked with "force_static".

[...]



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