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] More aggressive dead code elimination


In message <200401080151.47350.s.bosscher@student.tudelft.nl>, Steven Bosscher 
writes:
 >On Thursday 08 January 2004 00:10, Diego Novillo wrote:
 >> On Wed, 2004-01-07 at 17:52, law@redhat.com wrote:
 >> > In message <1073515593.6424.11.camel@frodo.toronto.redhat.com>, Diego
 >> > Novillo w
 >> >
 >> > rites:
 >> >  >On Wed, 2004-01-07 at 17:28, law@redhat.com wrote:
 >> >  >> We decided a few months ago against using this approach to DCE due to
 >> >  >> performance issues.
 >> >  >
 >> >  >Note that Steven's implementation can be switched between a fast and a
 >> >  >CD-driven DCE.  It would be interesting to gather some data now that we
 >> >  >have the two implementations.
 >> >
 >> > We discussed that too -- it's simply not worth maintaining the code.
 >>
 >> But we never actually gathered any data (not that I remember, anyway).
 >> I do suspect that CD-DCE may bring marginal benefits.  But, we have
 >> cases where we need to re-run DCE now.  Is it faster to run simple-DCE
 >> twice?  Or CD-DCE just once?  The CD-specific bits in the implementation
 >> look simple enough to maintain, too.
 >>
 >> The results are probably a wash, but I just don't know.
 >
 >Diego, Jeff,
 >
 >I just compiled the preprocessed GCC you sent me at -O2 with and
 >without the new DCE (CD-DCE).  User times on both is 10m5s, which
 >does not look like a performance issue to me.
 >
 >Here are the totals of the section sizes.
 >
 >	   text    data     bss     dec     hex filename
 >Old DCE	7526959    7161  618021 8152141  7c644d (TOTALS)
 >New DCE	7525650    7161  618021 8150832  7c5f30 (TOTALS)
 >
 >I also collected some data from runs on Gerald's test case.  The
 >timings are with "-O3 -fpermissive -w -quiet -ftime-report 8361.ii",
 >avarages of 5 runs with tree and misc checking enabled.
 >
 >	text		tree DCE	TOTAL
 >Old DCE	316367		0.67s		82.3s
 >New DCE	313089		0.87s		81.7s
 >
 >Huh? What? Faster overall? Yes.
 >
 >I'll try to produce some numbers (bootstrap times, and I hope SPEC
 >scores).
IIRC correctly, the canonical test for DCE performance was the two
big files from libjava.  However, interpret.cc may no longer be as
good of a test as we factor the computed gotos which prevents the
CFG & PHI explosion.  Why don't you get interpret.cc, disable
the computed goto factoring and look at the performance.

Ultimately if you can show better performance, then I'll be a lot
more willing to consider using the more aggressive DCE algorithm.



Jeff



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