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