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

[law at redhat dot com]

In message <20030510151224.GA31523@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >the problem with this approach is that you will eventually end up with
 >an uncomprehensible piece of code where everything depends on everything
 >and you cannot do a simplest change without everything else falling
 >apart.
Actually, I would claim we already in this state largely because 
we've parameterized every optimization pass based on the target's
characteristics.  As a result, it has become nearly impossible to
do work on our optimizers and have any confidence that the work will
be at least performance neutral on targets which do not closely 
match the developer's target machine.

Worse yet, the highly target dependent nature of our optimizers often
results in missed optimization opportunities.  For example, consider a
typical risc target which has limitations on what (if any) constants can
be used in a conditional jump.  I've seen many cases where global constant
propgation can prove that both arguments to the conditional are constants,
but due to the limitations of the target architecture we can't do the
replacements which will ultimately result in realization that the 
condition is a compimle time constant.

For this and other reasons I've come to the conclusion that we need to 
separate our optimizations into generic and target dependent optimizations.
And that conceptually the generic optimizations should strive to eliminate
as much redundancy as possible, fully propagate constants/copies, etc and
leave it to the expanders and target dependent optimizers to "undo" 
unprofitable redundancy elimination, cprop, etc.

 >GCSE is basically machine independent, so there should not be a need for
 >it to take machine-dependent issues into accout.
Right.  In fact, I've never been happy about some of the machine dependencies
we've introduced into GCSE.  For example, why in the hell should GCSE care
whether or not a particular port has properly defined its reload_[inout]_ccmode
patterns?  Well, gcse does care!  It may not be obvious, but 
AVOID_CCMODE_COPIES
was introduced to deal with this problem.  That's unbelievably silly.

It's probably worth keeping in mind that GCSE does have one large 
target dependency -- namely that each and every substitution made by GCSE
must result in a valid insn.  This is a huge target dependency -- and a
legitimate target dependency given where GCSE sits in the optimization path.

Jeff