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

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

On Saturday 17 January 2004 01:52, Daniel Berlin wrote:
> On Jan 16, 2004, at 7:34 PM, law@redhat.com wrote:
> > In message <87llo7ju9y.fsf@codesourcery.com>, "Zack Weinberg" writes:
> >> The level of testing being asked - and done - for this change is
> >> wildly out of proportion to the level of testing being done for other
> >> changes going onto the tree-ssa branch.
> >
> > That's because we have already been down this design decision before.
> > Steven effectively wants to bring back code we threw out about 6 months
> > ago because it had some significant compile time performance concerns
>
> Except that Steven's code doesn't, as he's quite clearly shown through
> multiple timings and testing *already*.

I'm going to speak for nobody but myself, based on own experience here.
And I'm in a terrible mood so if you feel insulted, so be it -- just
remember who said it and don't care as usual.

I have produced more numbers for my DCE patch than I have seen Jeff produce
for any patch he has produced.  I have showed that for the imput Jeff has
asked me to test, the impact of my DCE implementation is not nearly as bad
as Jeff thought it would be.  I have shown that the compile time impact is
in the noise, and if it is not the my patch is an improvement.  I've shown
this for the infamous interpret.cc for which I had to disable computed goto
factoring which is not something we'll ever do in real life, I've shown
numbers for Geralds 8361 test case and for Diego's cc1-i subset.  Timings
and binary sizes are all no worse or better than the existing code.  I've
tried to show that I've taken care of some of your worries off-list, and
did not get a reply.  I have  written the code such that the existing 
implementation and my changes do not conflict.  I don't think there is
anything more I can do to show that my code is both correct, an improvement,
and maintainable.

Bottom line: You just don't want this code.  Fine.  Next time say it when
I post the patch and don't ask me to provide proof because you've just shown
it doesn't make any difference anyway.

The same cannot be said for any change Jeff has contributed lately.  When I
first timed cc1-i, i got results in 8 minutes or less (7m58 with my patch).
This morning I tested again and now we need 8m20s.  There's only a week
between my first test and the runs I did this morning.  Where did this
slowdown come from?  I haven't seen any timings from anyone that indicated
that there was an expected slowdown to improve any code.  It just happens.
Looking at ChangeLog.tree-ssa, I'm pretty sure it wasn't me.  So why do I
have to go through a full week of intensive testing to prove that my code
doesn't significanly slow down tree-ssa when we've just regressed 5% 
unexplicably, unacccountably for no apparent reason?

I think that the amount of testing, the amount of evidence that has been
asked of me is ridiculous.  More so considering that Jeff and others just
commit stuff without public justification of their code.  I don't see Jeff
provide timings of the dominator optimizers, which are now by far the most
expensive tree-ssa optimiation passes.  I don't see SPEC numbers or any
other benchmarking.  It just is presented as "an improvement" and commited
wihtout further consideration.  I believe this is just unfair.

Call me a whiner, but so far AFAICT these are the facts.

Gr.
Steven