This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] More aggressive dead code elimination
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).
Gr.
Steven