On Wed, 1 Feb 2017, Richard Biener wrote:
> On Wed, 1 Feb 2017, Jakub Jelinek wrote:
>
> > On Wed, Feb 01, 2017 at 02:14:20PM +0100, Richard Biener wrote:
> > >
> > > 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)
> >
> > I'm worried that we don't want to handle all the constants that way.
> > As I wrote on IRC, I see some problematic constants:
> > 1) not sure if constants can't be
> > potential_nondependent_constant_expression, then we don't want to return
> > them
> > 2) cxx_eval_outermost_constant_expr has some special handling of
> > trees with vector type (and array type)
> > 3) constants with TREE_OVERFLOW should go through maybe_constant_value_1
> > 4) INTEGER_CSTs with POINTER_TYPE (if they aren't 0) likewise
> >
> > For 3) and 4) I believe maybe_constant_value is supposed to wrap the
> > constants into a NOP_EXPR or something.
>
> Just to mention, bootstrap & regtest completed successfully without
> regressions on x86_64-unknown-linux-gnu so we at least have zero
> testing coverage for the cases that break.
>
> I'll wait for Jason to suggest specific things to avoid, TREE_OVERFLOW
> and pointer types are easy (no need to special case zero, it's just
> one entry per pointer type).
Oh, and just to mention the same issue of course plagues
maybe_constant_init which ends up allocating a hash_map 1630776 times
(fixing that doesn't fix any memory-hog but would avoid some needless
cycles spent on this). Similar "simple" patch would be
* constexpr.c (maybe_constant_init): Bail out early
for CONSTANT_CLASS_P.
Index: gcc/cp/constexpr.c
===================================================================
--- gcc/cp/constexpr.c (revision 245119)
+++ gcc/cp/constexpr.c (working copy)
@@ -4916,6 +4919,8 @@ maybe_constant_init (tree t, tree decl)
t = TARGET_EXPR_INITIAL (t);
if (!potential_nondependent_static_init_expression (t))
/* Don't try to evaluate it. */;
+ else if (CONSTANT_CLASS_P (t))
+ return t;
else
t = cxx_eval_outermost_constant_expr (t, true, false, decl);
if (TREE_CODE (t) == TARGET_EXPR)
which is even eventually safer because it's after
the !potential_nondependent_static_init_expression (if that can
be ever true for CONSTANT_CLASS_P t).
Then the other issue noticed is that we always copy every
CONSTRUCTOR at least once via reshape_init_array.
I think both maybe_constant_value and maybe_constant_init are
low-hanging fruit to fix at this point so waiting for some
guidance on Jakubs concerns (or just take it yourself from here).
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);
> > >
