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: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: jh at suse dot cz
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 9 May 03 18:35:07 EDT
- Subject: Re: An issue for the SC: horrible documentation quality of GCC
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.
I'd call that a rather over-specified definition. I wouldn't say that a
key attribute of a CSE algorithm would be the insertion of those copies.
Indeed, cse.c doesn't *want* to do that since it would increase the number
of insns considerably. It's not at all clear to me that the number of
times such copies would win over the more straightforward approach that
cse.c does justifies the overhead in all the new insns and pseudos.
I agree that it makes sense for a global cse to do such a thing, however,
because then cse.c can clean it up.