Loop optimizer issues

[Zdenek Dvorak]

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

and then we complain that gcc is slow...

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

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.

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.

Zdenek