This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] New regressions as of 2003-11-04
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: law at redhat dot com
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Jan Hubicka <jh at suse dot cz>,Diego Novillo <dnovillo at redhat dot com>,Daniel Berlin <dberlin at dberlin dot org>,gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Mon, 10 Nov 2003 20:54:39 +0100
- Subject: Re: [tree-ssa] New regressions as of 2003-11-04
- References: <20031110192935.GA12790@atrey.karlin.mff.cuni.cz> <200311101942.hAAJgh1e019800@speedy.slc.redhat.com>
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