This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Rerunning CSE after GCSE
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: Rerunning CSE after GCSE
- From: Jeffrey A Law <law at redhat dot com>
- Date: Sun, 18 Feb 2001 17:33:58 -0700
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <10102190018.AA15505@vlsi1.ultra.nyu.edu>you write:
> I view this as a bit experimental, but when running a Benchmark (in Ada), I
> noticed that gcse's cprop was propagating the constant into the beginning o
> f
> a basic block, but not further. CSE is needed to propagate the rest of the
> way. But if the block in question is in a loop, loop.c may pull the
> propagation that gcse did outside the loop and the propagation will never
> occur.
>
> So it's worthwhile to run cse again after gcse. If if eliminates a jump,
> further propagation may be possible, so cse is now rerun until it finished
> propagating through jumps. I think we'll be able to eliminate this if we
> remove the skipping of blocks and following branch code from CSE and simpli
> fy
> it but we need measurements.
>
> Some tests I did showed this did not slow things down too much, but further
> investigation and measurements are clearly required.
>
> Sun Feb 18 15:45:17 2001 Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
>
> * toplev.c (note_deferral_of_defined_inlined_function): Argument
> FNDECL may be unused.
>
> * toplev.c (rest_of_compilation): Don't have CSE skip blocks or
> follow jumps after first run.
> If -fexpensive-optimizations rerun CSE after GCSE and iterate until
> it doesn't change any jumps.
Please don't do this. The two existing CSE passes already account for
50% of the compilation time for many large programs (particularly those
in the plumhall testsuite). Your change will have a *huge* impact on
our ability to run those tests in a reasonable timeframe.
We really need to speed up local CSE before running it anymore.
jeff