This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][C++] Improve memory use for PR12245
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Wed, 1 Feb 2017 16:16:49 +0100 (CET)
- Subject: Re: [PATCH][C++] Improve memory use for PR12245
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LSU.2.20.1702011411480.12993@r111.fhfr.qr> <20170201144109.GE14051@tucnak>
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).
Richard.
> > 2017-02-01 Richard Biener <rguenther@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);
> >