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: [tree-ssa] DCE with control dependence again (with numbers, for a change)


On Friday 16 January 2004 05:40, Jeff Laww wrote:
> In message, Steven Bosscher writes:
>  >Next, I tested 8361 at -O2 and -O3:
>  >
>  >current:
>  >Results for 8361.ii, flags=-O2, 3 runs:
>  >tree DCE		0.61	0.59	0.63
>  >TOTAL			57.66	57.53	57.59
>  >.text size:	320954
>  >
>  >Results for 8361.ii, flags= -O3, 3 runs:
>  >tree DCE		0.56	0.63	0.65
>  >TOTAL			58.98	58.96	58.96
>  >.text size:	315823
>  >
>  >current + patch:
>  >Results for 8361.ii, flags=-O2, 3 runs:
>  >tree conservative DCE	0.41	0.49	0.47
>  >tree aggressive DCE	0.26	0.32	0.29
>  >control dependence	0.04	0.05	0.01
>  >TOTAL			57.15	57.16	57.21
>  >.text size:	317702
>  >
>  >Results for 8361.ii, flags=-O3, 3 runs:
>  >tree conservative DCE	0.39	0.45	0.48
>  >tree aggressive DCE	0.26	0.29	0.24
>  >control dependence	0.02	0.07	0.04
>  >TOTAL			58.46	58.45	58.43
>  >.text size:	312524
>  >
>  >So we're slightly faster _with_ the patch (!), and the generated
>  >code is smaller.
>
> Just so I'm sure I understand the quoted numbers.  I'm assuming the
> tweak for abnormal edges is installed and that we run the conservative
> DCE for dce1/dce2 and aggressive DCE for dce3.  Is that correct?

That's right.

> If you've still got the raw data handy, I'd be *real* interested to know
> what got faster (if anything stands out).  For both the -O2 and -O3 tests,
> it appears that we spend about .1 seconds longer doing DCE related stuff
> with your changes -- yet the overall time dropped by about .5 seconds.
>
> Meaning that somewhere we got about .6 seconds faster.  We know it can't
> be the early SSA passes since the more aggressive DCE ran late in the
> SSA path.  Is the improvement bunched in the out-of-ssa code, expand,
> or is it spread across various passes after the final DCE pass?

I don't have the raw data handy, but of course this was one of the things
I was looking at myself.  There was no single pass that stood out We just
win over the whole line.

> The other datapoint I can derive is that a single call into the
> aggressive version is about 2X slower than a single call into
> the conservative version.  Meaning it's probably not a good idea to
> switch to the aggressive version exclusively.

Indeed.  That is why I only wanted to run it once.  I first thought that
running it early was a good idea, to get as much cruft out of the way
before running the other SSA optimizers.  That turned out to give us very
little.

>  >Finally, I looked at how big cc1 and cc1plus are with and without
>  >the patch:
>  >
>  >current:
>  >.text size of GCC binaries after bootstrap:
>  >cc1	3904480
>  >cc1plus	4367792
>  >
>  >current + patch:
>  >.text size of GCC binaries after bootstrap:
>  >cc1	3903181
>  >cc1plus	4366413
>  >
>  >So again we produce smaller binaries.  This is quite remarkable IMO
>  >because the new tree-ssa-dce code is much larger than the old one
>  >(.text size 4842 with current, .text size 8910 with the patch).
>
> Which doesn't make a lot of sense.  The components of cc1 only saw
> a reduction of 1k, would shouldn't have offset the 4k of additional
> code in the new tree-ssa-dce.  That's real strange.

Why doesn't it make sense?  The components in all cc1 object files
excluding tree-ssa-dce.o get a 5k reduction, but the new tree-ssa-dce
is 4k bigger.  These are binary sizes after bootstrap, one with the old
and one with the new DCE.

> I'm not real hot on the idea of doubling the size of our DCE code, but
> it's clearly the case that there's room for improvement.  And at least
> if we double the size of the code it's based on well known and understood
> algorithms.

So, does this, along with Diego's opinion, mean it's approved?

Gr.
Steven


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