Re: Loop optimizer issues

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

    > 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.

    and then we complain that gcc is slow...

They don't slow things down, or at least not signficantly.  It's usually just
a matter of a case of a switch statement that never gets executed or similar
test.

    Simplicity. Clear and extendable code without unnecessary redundancies
    and relicts of code that does nothing, but nobody dares to touch it in
    case it actually did.

I see it as precisely the other way around!  If you write code to handle all
cases, you don't have to document why you aren't handling some of them and
worry about whether you might have to handle those cases when something
changes.  Optimizers are more independent and easier to maintain when they
make as few assumptions as possible about what previous passes have done.

    Yes, it is not somehow terribly difficult to handle LIBCALLs; but the
    only reason for their existence is that they represent too complicated
    constructions to manipulate as whole otherwise; and this reason should
    cease to exist with tree-ssa.

I wasn't talking specifically about LIBCALLs, but even in that case, I'm not
sure I agree.  Handling LIBCALLs only adds a few lines of to well-writen
code, so I'd invoke the above (assuming some other pass optimizes them) to
argue that it's simpler to handle them than not to.