On 1/6/22 11:02, Martin Liška wrote:
On 1/6/22 16:11, Andrew MacLeod wrote:
On 1/5/22 07:34, Richard Biener wrote:
On Thu, Dec 9, 2021 at 2:02 PM Martin Liška <mli...@suse.cz> wrote:
On 11/30/21 12:17, Richard Biener wrote:
+ unswitch_predicate *predicate
+ = new unswitch_predicate (expr, idx, edge_index);
+ ranger->gori ().outgoing_edge_range_p
(predicate->true_range, e,
+ idx,
*get_global_range_query ());
+ /* Huge switches are not supported by Ranger. */
+ if (predicate->true_range.undefined_p ())
I hope ranger will set the range to varying_p () in that case, not
undefined? But even
then, is that a reason for punting? I guess we fail to prune cases in
that case but
the cost modeling should then account for those and thus we are at
least consistent?
huge switches not supported? I don't know what you mean, either that
or I forget :-) If there are more edges than multi-ranges support,
then things will start getting merged because they cant be
represented.. and the default case may then also contain some values
that also have cases.. but all inconsistencies will move towards
varying.. not undefined.
Andrew
oh oh oh. EVRp was spending too much time in very large switches, so
we added a param to say "don't look at switches too big" You are
probably tripping over that
-param=evrp-switch-limit=
Common Joined UInteger Var(param_evrp_switch_limit) Init(50)
Optimization Param
Maximum number of outgoing edges in a switch before EVRP will not
process it.
and in GORI we check:
// Do not process switches if they are too large.
if (EDGE_COUNT (bb->succs) > (unsigned)param_evrp_switch_limit)
return;
so maybe you want to temporarily override param_evrp_switch_limit to
some big number for your purposes... just set it back when you are done :-)
Andrew
