Re: [PATCH][RFC] Unify MAX_NUM_CHAINS and MAX_CHAIN_LEN to --param uninit-max-predicate-size

[Jeff Law <jeffreyalaw@gmail.com>]

On 9/5/22 07:25, Richard Biener via Gcc-patches wrote:
> The following exposes the MAX_NUM_CHAINS and MAX_CHAIN_LEN to the user
> by adding a --param uninit-max-predicate-size and re-doing the
> limits on the whole predicate expression size rather than limiting
> the number of OR and AND elements separately.  The following goes
> a step further and for a single AND chain allows an arbitrary size,
> limiting that only with the computational --param
> uninit-control-dep-attempts parameter.  That might be a bit high
> in practice, but it seems odd to continue searching for smaller and
> smaller paths until we exhaust the search space or
> uninit-control-dep-attempts.
>
> I'm testing this on x86_64-unknown-linux-gnu at the moment.
>
> Any comments?
>
> Thanks,
> Richard.
>
> 	* params.opt (uninit-max-predicate-size): New.
> 	* doc/invoke.texi (--param uninit-max-predicate-size): Document.
> 	* gimple-predicate-analysis.h
> 	(predicate::init_from_control_deps): Adjust.
> 	* gimple-predicate-analysis.cc (MAX_NUM_CHAINS, MAX_CHAIN_LEN):
> 	Remove.
> 	(format_edge_vecs): Adjust.
> 	(simple_control_dep_chain): Do not limit.
> 	(compute_control_dep_chain): Adjust limiting to the overall
> 	predicate expression size _after_ adding an element to the
> 	vector of AND chains.
> 	(predicate::init_from_control_deps): Adjust.
> 	(uninit_analysis::init_use_preds): Likewise.
> 	(uninit_analysis::init_from_phi_def): Likewise.

I think we probably have too many knobs already, though magic numbers 
are even worse.  I suspect we (gcc develoeprs) will be the biggest user 
of this if we go forward.  Essentially given a testcase we can crank up 
the limits to see if the test is hitting limits or exposing a deeper 
problem.

So based on removal of the magic #s, it looks good to me.


jeff