This is the mail archive of the gcc@gcc.gnu.org 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] |
In message <10307031832.AA09072@vlsi1.ultra.nyu.edu>, 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 >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. 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. jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |