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