https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #28 from Mark Wielaard <mark at gcc dot gnu.org> --- (In reply to Filip Kastl from comment #24) > One way to fix this would be to not apply the switch size limit on jump > tables. Since finding jump tables is at least O(n^2), this could > theoretically cause long compile times in some specific cases. However, > nobody has reported any bug of that kind yet. There is only pr117091 for > bit tests. That pr would remain fixed, I believe. > > Do we want to do that, though? Maybe GCC taking this long to compile > something just because we didn't use jump table lowering is a sign of a > problem in a different pass? I haven't tried yet, but do you mean something like the following? diff --git a/gcc/tree-switch-conversion.cc b/gcc/tree-switch-conversion.cc index b98e70cf7d16..74abc74d842b 100644 --- a/gcc/tree-switch-conversion.cc +++ b/gcc/tree-switch-conversion.cc @@ -1643,10 +1643,6 @@ jump_table_cluster::find_jump_tables (vec<cluster *> &clusters) unsigned l = clusters.length (); - /* Note: l + 1 is the number of cases of the switch. */ - if (l + 1 > (unsigned) param_switch_lower_slow_alg_max_cases) - return clusters.copy (); - auto_vec<min_cluster_item> min; min.reserve (l + 1);
