This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] More aggressive dead code elimination
- From: law at redhat dot com
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: Diego Novillo <dnovillo at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 07 Jan 2004 20:15:53 -0700
- Subject: Re: [tree-ssa] More aggressive dead code elimination
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Steven Bosscher
>On Thursday 08 January 2004 00:10, Diego Novillo wrote:
>> On Wed, 2004-01-07 at 17:52, email@example.com wrote:
>> > In message <firstname.lastname@example.org>, Diego
>> > Novillo w
>> > rites:
>> > >On Wed, 2004-01-07 at 17:28, email@example.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.
>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
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.