Change default for jump_table expansion ratio to 8.

2018-06-20  Martin Liska  <mliska@suse.cz>

	* 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 4106e0415980607af63b389426aea0a3d5c4fa89..c2639798fb34232ddd32f1f0bd666c4e6db11570 100644 (file)
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2018-06-20  Martin Liska  <mliska@suse.cz>
+
+       * tree-switch-conversion.c (jump_table_cluster::can_be_handled):
+        Change default ratio from 10 to 8.
+
 2018-06-20  Martin Liska  <mliska@suse.cz>
 
        * 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 a438960f8bfc3eb697789753939c009d51cec078..62ae884947499a39341ae113c7a20d1f8f210a55 100644 (file)
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -1165,17 +1165,11 @@ jump_table_cluster::can_be_handled (const vec<cluster *> &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 ());