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: Jan Hubicka <jh at suse dot cz>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: jh at suse dot cz, gcc at gcc dot gnu dot org
- Date: Sat, 10 May 2003 00:23:59 +0200
- Subject: Re: An issue for the SC: horrible documentation quality of GCC
- References: <10305092222.AA19835@vlsi1.ultra.nyu.edu>
> No, the CSE algorithm as usually defined in the books would simplify
> for instance:
> (set (reg a) (plus b c))
> (use a)
> (set (reg a) (something else))
> (set (reg b) (plus b c))
>
> But our alrgorithm won't, but it would do different things CSE described
> in the books won't, so it is not CSE as rest of the world know it and
> naming it CSE is missleading.
>
> Well I'm not sure what the "usual" cse algorithm would simplify this into
> since the result of the addition is no longer around, but defining an
> algorithm by what it would do in an obscure case seems odd to me.
The definition I find in all three books on compilers I have the
algorithm is documented as maintaining hash of available expressions and
when there is a hit it inserts a copy instruction at one side and use on
the other. This is what GCSE does.
It is not too odd situation, it is what you usually get after the
(manual) loop unrolling when same variables are reused many times for no
good reason.
The global optimizers are usually described as group of three main
passes: copy propagation, constant propagation and CSE (PRE), each
having local and global pass. This is what I would like to slowly
converge into. We do have all the main bits in place, just they are
twisted.
Honza