On Tue, Jul 2, 2013 at 1:16 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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.
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
