Re: Loop optimizer issues

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    how will you judge that without actually trying it?

    In this concrete instance there is not much guessing, really.  There
    will be some code motion done on tree-ssa as well as on rtl; the only
    question is how much will be done where.

Right.  And why try to guess in advance?  The GCC strategy has always been to
do optimizations when we get the opportunity rather than to try to deduce by
some analytical method which ones are actually used when.  I'm sure there are
plenty of RTL simplifications that can't actually occur anymore due to the
interaction of other optimizations, but there's no point in removing them
since yet more changes might produce them again.

Similarly for loop optimizations.  What do we gain by purposely cripling a
pass to avoid certain optimizations because we think others might be doing
it?  Clearly in some cases if the optimizations being avoided are very
expensive, we don't want to do them, but this isn't one of those cases.

To give a counterexample that I mentioned a number of times, the CSE
optimizations that go around branches and such are very expensive.
When I wrote them, they were supposed to be made obsolete by a global
CSE, but they weren't.  Since those optimizations *are* quite
expensive, it would be good to eliminate them.  Perhaps tree-ssa will
allow us do that, but in that event, we'd merely be covering up some
bug in GCSE: I'd prefer to actually fix it.