An issue for the SC: horrible documentation quality of GCC

[Richard Kenner]

    Well, when dead code is removed this will look like:

      p2 <-- 100 + p3

Only if p1 is, in fact, dead.

    But this needs to be determined at a later point, instead of cluttering
    all the optimization passes with machine dependend checks.

You lost me here.  All of RTL and every choice within it is implicitly
machine-dependent.  Every cost calculation is machine-dependent.  The
entire RTL optimization strategy is based on making machine-dependent
decisions (of course, written in machine-independent ways).

    CSE as we implement it is fundamentally different from gcse.  For one
    our CSE is not any CSE but a kind of ad hoc value numbering
    intertwined with expression simplification.

Again, you lost me.  It eliminates common subexpressions.  Isn't that what
"cse" stands for?

    And I can't find a function in cse.c which does something similar
    (i.e. just propagating constants and copies).  

Well, fold_rtx, I suppose, but that's because it does everything at
one time.  And, as I've pointed out, it's not always better to
substitute a constant for a register: sometimes, it's best to do it
the other way around.  I have a favorite example for this:  the (non-obsolete)
ROMP chip had an ABI where the return register and the first argument 
register were the same. It also had a conditional return insn.  So if you
have a function with one operand, say X, and you have:

	if (x == 0)
	  return 0;

What you really want to do with the insn setting the return value is
to change *from* the 0 *to* the equivalent, X.  That way that insn is a
no-op, and you can do this as a conditional return insn.

CSE gets this right because it uses the cost metric.  It sounds like the
code in gcse.c will get this wrong.

    Like I said, local_cprop* has nothing to do with gcse itself, except being
    run to clean up the code between the gcse iterations.

Then that's all the *more* reason why it should be documented!