Looks like we cache the answer to maybe_constant_value (INTEGER_CST) which results in (-fmem-report):
cp/constexpr.c:4814 (maybe_constant_value) 67108816:100.0% 100663104 17: 0.0% ggc this can be improved trivially to cp/constexpr.c:4817 (maybe_constant_value) 2032: 13.6% 2144 2: 0.0% ggc with the following patch which I am testing right now. Ok for trunk? (just in case it causes some fallout because, err, some tcc_constant is not really constant, what's the subset we can cheaply check here? basically we want to avoid caching all INTEGER_CSTs we use for CONSTRUCTOR_INDEX in large initializers) Thanks, Richard. 2017-02-01 Richard Biener <rguent...@suse.de> cp/ * constexpr.c (maybe_constant_value): Do not cache CONSTANT_CLASS_P nodes. Index: gcc/cp/constexpr.c =================================================================== --- gcc/cp/constexpr.c (revision 245094) +++ gcc/cp/constexpr.c (working copy) @@ -4810,6 +4810,9 @@ static GTY((deletable)) hash_map<tree, t tree maybe_constant_value (tree t, tree decl) { + if (CONSTANT_CLASS_P (t)) + return t; + if (cv_cache == NULL) cv_cache = hash_map<tree, tree>::create_ggc (101);