Re: [PATCH][C++] Improve memory use for PR12245

[Jason Merrill <jason at redhat dot com>]

On Thu, Feb 2, 2017 at 4:21 AM, Richard Biener <rguenther@suse.de> wrote:
> 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).

Yeah, I think doing the early return after potential_nondependent_* is
the way to go.  Here's what I'm applying:

Attachment: 12245.diff
Description: Text document