[cfe-commits] [PATCH] New compile-time constant value representation

[Eli Friedman]

On Fri, Dec 2, 2011 at 11:09 AM, Richard Smith <richard at metafoo.co.uk> wrote:
> Hi,
>
> During the implementation of C++11 constexpr support, it's become clear that
> APValue is far from ideal as a representation of compile-time constants. In
> particular, for large structs or arrays, its in-memory representation is
> extremely wasteful and very malloc-heavy, and its interface results in many
> unnecessary APValue copies.
>
> Attached is a rewrite intended to solve these problems. This separates the
> storage of the constant value (ConstValueStorage, a bump ptr allocated lump of
> memory) from the constant value traversal / updating interface (the ConstValue
> class hierarchy, modeled on TypeLoc). Only one allocation is performed for a
> full-object, in the common cases.
>
> I've not finished integrating this into the rest of clang (and removing
> APValue) yet, so I sadly can't give any measured numbers for the change in
> performance and memory usage from this change. However, some quick
> calculations on SPEC's 445.gobmk's josekidb.c, on x86_64, indicates this
> should reduce ~65000 mallocs of a total of about 10.9MB to ~1000 bump
> allocations of a total of about 260KB (if we built that file in C++11 mode).
> For reference, the AST nodes which store the initializers in this file occupy
> ~16MB.
>
> Reviews of the approach and the code itself would be very much appreciated; if
> the result of such a review is "Don't do it this way!", I'd much rather know
> sooner than later.

The approach seems feasible, in terms of the in-memory representation.
 I'm not sure under what conditions we need ExtendedInfo for
addresses; I'm hoping we don't need it for common global+offset cases?
 Also, is it feasible to make the representation of arrays sparse? For
cases with tail padding, it looks like the evaluated representation
could be much larger than the AST.

The interface seems mostly fine.  It might be nice to have non-APValue
accessors in a few cases where we don't need the generality of
APValue: for example, it would be nice to fast-path small integers for
IRGen.

-Eli