From 11060716567dfa478d05b8734e5f301bcde7f568 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 20 Jun 2018 08:52:55 +0000 Subject: [PATCH] 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. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@261795 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 5 +++++ gcc/tree-switch-conversion.c | 10 ++-------- 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 4106e0415980..c2639798fb34 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 a438960f8bfc..62ae88494749 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 ()); -- 2.47.2