This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: [patch] fix pr22550


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.

In terms of code generation, there are absolutely no differences.
I got identical results in all the SPEC testers (x86, x86-64 and
ppc64).

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.

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 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.

Attachment: 20050726-22550-dont-propagate-in-cfg-cleanup.diff
Description: Text document

Attachment: 20050726-22550-iterate-cleanup.diff
Description: Text document


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