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: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, 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 12:47:33 -0700
- Subject: Re: [tree-ssa] New regressions as of 2003-11-04
- Reply-to: law at redhat dot com
In message <20031110194035.GA14398@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>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? Otherwise I don't see how the timing is
>> > relevant. 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.
>>
>> This kind of reasoning is why GCC is slowing down all the time.
>>
>> Yes, a pass over all statements _does_ have a compile time impact. Especia
>lly
>> if we keep adding new ones by the dozens claiming that they don't impact
>> compile time.
>
>well, the only thing I tried to argue is that the solution I use cannot
>be slower than the previous one. I did't not intend to argue about
>usefulness of the pass, since I believe that people who put its
>equivalent there did know what they are doing.
But you're version is doing more work than the old one in particular keeping
the CFG up-to-date. Now it is likely the case that keeping the CFG up-to-date
isn't a huge cost, but then again, if you haven't measured it, how do we
actually know what that cost is?
Simply saying it cannot be slower does not make it a fact.
Jeff
Jeff
>
>Zdenek