This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: An issue for the SC: horrible documentation quality of GCC
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 10 May 2003 19:18:22 +0200
- Subject: Re: An issue for the SC: horrible documentation quality of GCC
- References: <10305101709.AA23764@vlsi1.ultra.nyu.edu>
Hello,
> I guess that for every such heuristic you will with some care find an
> example where it does a stupidity. In general it makes more sense to
> have a few passes with really good heuristics than have some lame
> heuristic in every pass.
>
> No, all should be good!
good luck. If you want them be really good, they must all work globally.
They must alst take into account what any other later optimization could
do. This is not feasible.
> The strength of GCC is that it does optimization
> everywhere. We should not sacrifice that.
The strength of gcc is that it has several fairly good passes, including
the "CSE". Unfortunately it is also a great weakness, as in order to
make them produce so good code we have sacrificed other important
criterions what "good" means.
> As for the speed -- I guess this is just a matter of opinion, as there
> is nothing to compare. My opinion is that the increased speed of most
> of the passes would pay up for the decreased speed of a few cleanup
> passes (they must be in some form present anyway, they already must
> gather all the data, so the slowdown should not be that dramatic).
>
> Increased over what? Why does a heuristic slow things down?
Why it should not? You must gather the data on that you base your
decison, which definitely is not fast if you want to do it everywhere.
Zdenek