This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Loop optimizer issues

In message <>, Richard Kenner writes:
 >    > 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.
LIBCALL are a royal PITA.  Each and every RTL optimizer has been hacked
over and over to deal with them.  It's not just a few lines of well-written
code.  It's dozens and dozens in lots of different places.

There was also a time (roughly a year ago) that the single most called function
in the compiler was find_reg_note from sites where we were trying to
find the bounds of libcall blocks.

libcalls are a disgusting hack and I can't see any way I'd consider tree-ssa
a success if libcalls survive in the long term.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]