From: Martin Liska Date: Wed, 20 Jun 2018 08:52:55 +0000 (+0200) Subject: Change default for jump_table expansion ratio to 8. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=de840bde88a7719fa022f1de6f4e407bf5b4c8a8;p=gcc.git Change default for jump_table expansion ratio to 8. 2018-06-20 Martin Liska * tree-switch-conversion.c (jump_table_cluster::can_be_handled): Change default ratio from 10 to 8. From-SVN: r261795 --- diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 4106e041598..c2639798fb3 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2018-06-20 Martin Liska + + * tree-switch-conversion.c (jump_table_cluster::can_be_handled): + Change default ratio from 10 to 8. + 2018-06-20 Martin Liska * tree-switch-conversion.c (jump_table_cluster::find_jump_tables): diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c index a438960f8bf..62ae8849474 100644 --- a/gcc/tree-switch-conversion.c +++ b/gcc/tree-switch-conversion.c @@ -1165,17 +1165,11 @@ jump_table_cluster::can_be_handled (const vec &clusters, make a sequence of conditional branches instead of a dispatch. The definition of "much bigger" depends on whether we are - optimizing for size or for speed. If the former, the maximum - ratio range/count = 3, because this was found to be the optimal - ratio for size on i686-pc-linux-gnu, see PR11823. The ratio - 10 is much older, and was probably selected after an extensive - benchmarking investigation on numerous platforms. Or maybe it - just made sense to someone at some point in the history of GCC, - who knows... */ + optimizing for size or for speed. */ if (!flag_jump_tables) return false; - unsigned HOST_WIDE_INT max_ratio = optimize_insn_for_size_p () ? 3 : 10; + unsigned HOST_WIDE_INT max_ratio = optimize_insn_for_size_p () ? 3 : 8; unsigned HOST_WIDE_INT range = get_range (clusters[start]->get_low (), clusters[end]->get_high ());