This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: An issue for the SC: horrible documentation quality of GCC


>     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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]