------- Comment #4 from steven at gcc dot gnu dot org 2010-01-05 22:11 -------
I would just go back to the old status (of GCC 4.3 and earlier) than deciding
for each basic block individually whether to unfactor or not.
Could you please see if the attached problem makes the slow-down disappear?
Index: bb-reorder.c
===================================================================
--- bb-reorder.c (revision 155661)
+++ bb-reorder.c (working copy)
@@ -1981,7 +1981,9 @@ gate_duplicate_computed_gotos (void)
{
if (targetm.cannot_modify_jumps_p ())
return false;
- return (optimize > 0 && flag_expensive_optimizations);
+ return (optimize > 0
+ && flag_expensive_optimizations
+ && ! optimize_function_for_size_p (cfun));
}
@@ -2072,9 +2074,6 @@ duplicate_computed_gotos (void)
|| single_pred_p (single_succ (bb)))
continue;
- if (!optimize_bb_for_size_p (bb))
- continue;
-
/* The successor block has to be a duplication candidate. */
if (!bitmap_bit_p (candidates, single_succ (bb)->index))
continue;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
