This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] PR15242


This patch is a first shot at fixing PR15242, a regression from
GCC 3.2.  A similar patch was proposed months ago by Josef Zlomek,
but it never got a proper review.

The issue is that we factor computed gotos early in the optimization
path to make the cfg less dense.  This makes data flow solvers a lot
faster.  But we never properly unfactor the computed jump again, and
this results in slowdowns of as much as 300% in real world code like
interpreters and simulators.

With the attached patch, we unfactor the computed gotos as late as
possible.  The solution is suboptimal - it would be better if we
could unfactor before scheduling for example - but this patch seems
to do the job well enough to fix the regression.

There is the hard-coded "8" in bb-reorder.c.  Probably that should
be a param.  The only reason that it is not, is because I couldn't
come up with a good name for it ;-)  Suggestions are welcome.

Bootstrapped and tested on {ia64,i686}-suse-linux-gnu.  I have also
checked that we unfactor the computed jumps for a Prolog interpreter
that suffered from this regression.

Comments?  OK for mainline?


PR optimization/15242
* basic-block.h (duplicate_computed_gotos): Add prototype.
* bb-reorder.c (bb_insn_length): New function.
(copy_bb_p): Use it.
(duplicate_computed_gotos): New function to duplicate sufficiently
small blocks ending in a computed jump.
* passes.c (rest_of_compilation): Call duplicate_computed_gotos
if not optimizing for size.
* cfgcleanup.c (try_crossjump_bb): If not optimizing for size,
never do tail merging for blocks ending in a computed jump.

Attachment: patch.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]