[patch] fix pr22550

[Jeffrey A Law]

On Thu, 2005-07-28 at 11:56 -0400, Diego Novillo wrote: 
> On Tue, Jul 26, 2005 at 11:33:20AM -0600, Jeffrey A Law wrote:
> 
> > So the question becomes whether or not removing them in the CFG
> > cleanup code rather than in the regular optimizers provides
> > us with some benefit -- compile-time speedup, or possibly 
> > secondary optimization opportunities that would be missed if
> > we killed these degenerate PHIs and merged blocks in a
> > later optimization pass.
> > 
> I experimented with both approaches and, contrary to what I had
> expected, iterating inside CFG cleanup is the winner.  Both
> patches are attached.
Wow.  I never would have expected this...

> However, iterating over CFG cleanup gives us a nice compile time
> reduction in DOM which sometimes translates to a minor overall
> time reduction:
> 
> DOM time    Before  After   % change
> --------------------------------------
> cc1files    26.64   16.53    -38.0%
> DLV         12.75    8.88    -30.4%
> MICO         6.24    5.44    -12.8%
> TRAMP3D      3.60    2.99    -16.9%
> SPEC2000    14.68   10.59    -27.9%
> 
> The reason for this reduction is that CFG cleanup now leaves
> fewer opportunities for DOM to work with.  I've seen some garbage
> collection reduction as well.  The straightforward
> transformations done during CFG cleanup are saving us from the
> heavier processing done during DOM.
Hmmm, I can hazard a guess it's more a matter of preventing DOM
iteration rather than fewer opportunities for DOM.

DOM iterates if it threads jumps *and* the CFG cleanup code actually
does something interesting.  By being more aggressive during normal
CFG cleanup, we may be avoiding "interesting" CFG cleanups at the
end of DOM and thus avoiding iterating DOM.

If we really wanted to understand this behavior, that's where I'd
look first -- how many DOM iterations do we have with the two
approaches.


> In fact, looking at the cleanup code, it would not be hard to
> teach it to flag an SSA update if it needed to.  This would
> harden CFG cleanup from messing up the SSA form.  There was a PR
> for it which Andrew had fixed by preventing CFG cleanup from
> propagating constants.  Andrew, remember the number?  It may be
> worth exploring that route.
I think there's a couple of PRs related to this issue.


> I plan to go with the iterative CFG cleanup, but I'd like to hear
> opinions first since this is a different conclusion to what I had
> in mind earlier this week.
I'd tend to agree.  It may be worth revisiting as we continue to
rip out stuff from DOM, but right now the numbers clearly show
we're better off with iterative CFG cleanup.

jeff