This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hello,

>  >>  >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.

I meant that it does nothing important with cfg; thus making the timings
of the original one quite uninteresting.

>  > 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.

It does not do any more or less work than the previous solution does; I
admit I did not measure it, but I would be really surprised if there was
any difference.  I will do the measurements, but it seems utterly stupid
waste of time to me.

>  >> 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.

I know about the one revealed by gcc.dg/tree-ssa/20030814-4.c and
gcc.dg/tree-ssa/20030814-5.c tests; this is IMHO the only reason why to
leave some form of post-tree-ssa cleanup.  Then there are some
superfluous goto removals, that should be done by cfg cleanup instead.
Anything else?

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]