Re: [tree-ssa] New regressions as of 2003-11-04

[law at redhat dot com]

In message <20031110192935.GA12790@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >>  >Huh??? Timings of what?
 >> When I wrote remove_useless_stmts_and_vars I actually took the time to
 >> measure how it impacted compile-time performance.
 >
 >you wrote it working on cfg?
No, I'm referring to the original implementation.

 > Otherwise I don't see how the timing is relevant. 
It it quite relevant since those timings indicated that removing useless
statements and variables resulted in an overall compile-time improvement.

You've stated that "Concerning compile time -- there is nothign much to
worry about, since no transformation done by remove_useless_stmts_and_vars
does anything important with it".

I see my timings as highly relevant given your statement.


 > Anyway, my patch does not change cfg at all and the only
 >thing it does is a simple pass over all statements, so I don't see a
 >potential for it to be slow.
Again, have you actually measured it?  As we all should know, code which
seemingly ought to run reasonably fast can for unexpected reasons run
slow.  Just stating that "I don't see a potential for it to be slow" is
not sufficient, particularly when we're working so hard to address the
compile-time issues on the branch -- doubly so when you're modifying/replacing
a pass who's primary purpose is to improve compile-time performance.


 >> I want you to sit down and look at the dumps.  Just saying you copied
 >> everything isn't sufficient since you don't actually know if it's working.
 >
 >You really believe I did not look at them, or what?  Sorry that I did
 >not state it explicitly, but I assume we are both inteligent people who
 >don't need to say every self-evident thing.
Based on my experience with you LOOP_EXPR patch and COND_EXPR patch, yes
I think you need to state it explicitly.  Just like we state explicitly
that we bootstrap and perform regression testing.

 >> You didn't do this kind of analysis with the COND_EXPR lowering code
 >> for example, and if you had done so you probably would have noticed that
 >> were were missing many transformations that were working with the old
 >> COND_EXPR code, but were not working with the new COND_EXPR code.
 >
 >Yes I did, and I stated it clearly when I posted the patch. And since
 >they were mostly useless, I ignored it.
Apparently you weren't looking that closely.  I have found numerous
transformations we were missing because of the COND_EXPR lowering patch.

Jeff