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);
