This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [BENCHMARK] runtime impact of fix for target/17390 on i386 targets
- From: Steven Bosscher <stevenb at suse dot de>
- To: ubizjak at gmail dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 20 Oct 2005 11:03:43 +0200 (CEST)
- Subject: Re: [BENCHMARK] runtime impact of fix for target/17390 on i386 targets
- References: <bug-17390-1649@http.gcc.gnu.org/bugzilla/> <20051019131357.13048.qmail@sourceware.org> <1129797952.43575940d06c0@ssl.kss-loka.si>
On Oct 20, 2005 10:45 AM, Uros Bizjak <uros.bizjak@kss-loka.si> wrote:
> I got following times:
>
> 1m37.986
> 1m37.139
> 1m38.410
>
> And _with_ patch:
>
> 1m37.264
> 1m37.352
> 1m37.383
>
> I would say that the difference is burried in noise.
It is still an extra pass over all instructions in the function. We've
gone from a few dozen to a few hundred passes over the whole function
since early GCC3 releases. And you're proposing to add another pass...
Â
_All_ changes we've done in the past, say, four years had compile time
impacts "in the noise". And probably they were. But the overall effect
is a huge slowdown. It's the accumulation of "noise" that hurts.
Â
So, these timings, and timings in general, don't mean anything to me.Â
The fact is that there is another new pass over all instructions, and if
we keep adding enough of those, all of them with cost "in the noise",
we'll be slowing down even further.
Â
And FWIW, it is IMHO bad practice in general to just add new passes,
instead of investigating why existing passes don't do the job and how
they can be enhanced to do the job better.
Â
It's also not a particularly great idea to duplicate a lot of code (like
you did, from the CC-cse pass), and I thought machine-specific
optimization passes are a no-no unless there really, _really_ is no way
to do the optimization elsewhere in the shared code.
Gr.
Steven