This is the mail archive of the
mailing list for the GCC project.
Re: Loop optimizer issues
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rakdver at atrey dot karlin dot mff dot cuni dot cz
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 3 Jul 03 14:32:18 EDT
- Subject: Re: Loop optimizer issues
> 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
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.