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
