[patch] PR15242

[Mark Mitchell]

Steven Bosscher wrote:
> Hi,
> 
> 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?

This looks good to me, except make that "8" into 
"max-goto-duplication-insns".  Not a great name, but a name.

(You could also make your patch more efficient by changing 
"bb_insn_length (bb) <= max_size" into "bb_insn_length_le (bb, 
max_size)", as you could then stop iterating through the block once it 
got big.  That would reduce that check from O(insns-in-block) to O(1).)

I'll approve the patch with those changes -- but please hold off for 48 
hours to give other people with more expertise a chance to object.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304