Re: [tree-ssa] DCE with control dependence again (with numbers, for a change)

[law at redhat dot com]

In message <200401161022.43265.stevenb@suse.de>, Steven Bosscher writes:
 >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.
OK.


 >>  >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.
Because your earlier test which measured the size of the cc1 components
only saw a 1k reduction.

 >> 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?
There's a couple things I want to check.  Particularly if you took the
algorithm from Morgan/Muchnick -- they gloss over at least one nasty
issue that can lead to incorrect code generation.

Jeff