On Thu, Apr 02, 2020 at 12:44:32PM +0200, Richard Biener wrote:
> > For the PR in question, my proposal would be to also lower
> > -param=max-find-base-term-values=
> > default from 2000 to 200 after this, at least in the above 4
> > bootstraps/regtests there is nothing that would ever result in
> > find_base_term returning non-NULL with more than 200 VALUEs being processed.
>
> Sounds good to me.
Here is what I've committed after another bootstrap/regtest on x86_64-linux
and i686-linux.
2020-04-02 Jakub Jelinek <ja...@redhat.com>
PR rtl-optimization/92264
* params.opt (-param=max-find-base-term-values=): Decrease default
from 2000 to 200.
--- gcc/params.opt.jj 2020-03-21 18:29:59.102158469 +0100
+++ gcc/params.opt 2020-04-02 13:05:14.433729117 +0200
@@ -663,7 +663,7 @@ Common Joined UInteger Var(param_max_var
Max. size of var tracking hash tables.
-param=max-find-base-term-values=
-Common Joined UInteger Var(param_max_find_base_term_values) Init(2000) Param
Optimization
+Common Joined UInteger Var(param_max_find_base_term_values) Init(200) Param
Optimization
Maximum number of VALUEs handled during a single find_base_term call.
-param=max-vrp-switch-assertions=
Jakub
