Re: V3 PATCH: Static data members

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Gabriel" == Gabriel Dos Reis <gdr@codesourcery.com> writes:

    Gabriel> The compiler should ideally do any nifty optimization.
    Gabriel> But the compiler we use for the moment doesn't and as
    Gabriel> implementors we have to cope with it as we can in order
    Gabriel> to reduce the abstraction penalty.

Trust me -- you have worse problems that static data members! :-)

There are two important ways the compiler can fail to optimize static
data members:

  - It can not fold their values in computations that involve them.
    This costs time.

  - It can emit them in object files where it doesn't need to.
    This costs space.

The second doesn't really impact the traditional "abstraction penalty"
measurement.  It would take some really bizarre program before the
amount of space allocated to static data members was a significant
part of the space used by the program.

So, I assume you have a case where the compiler generates worse code?

    Gabriel> Get real!  I would appreciate any patch from you to
    Gabriel> improve the compiler in that area.

Send me a test case. :-)

    Gabriel> | ... I would recommend that in V3 we do | what we think
    Gabriel> makes the cleanest code; if the compiler generates |
    Gabriel> inferior code file a bug against the compiler.

    Gabriel> On the contrary, I think we should cope with the compiler
    Gabriel> limits and reduce the abstraction penalty when possible.
    Gabriel> Users are after quality (and footprint happens to be one
    Gabriel> the criteria); purity is secondary.

OK, maybe you *are* worried about the space used.  See above for why I
don't think those are very important...

Of course there is a tradeoff -- as library implementors you cannot
simply say "well, the compiler should do a great job, so I don't have
to do anything".  On the other hand, you must beware making the same
mistake that glibc did with the horrid string optimization macros, or
that libstdc++ V2 did with the funny libio games.  (The second is more
excusable than the first in that you really do get some performance
win relative to what the compiler could ever do; with the string
stuff, the compiler should simply be taught the right optimizations.)

We are on the same team, compiler folks and library folks.  If the
compiler has limitations that are making it hard to get V3 to perform
well, we need to know about that.

Anyhow, the #1 thing users are after is correctness, and we don't have
that yet -- in either the compiler or the library.  So, ... :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com