On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote: > ld. > > However, I think that before anyone starts hacking anything, we should > come to a consensus on an overall strategy and implement something > consistent for the entire compiler rather than attack some particular > pass in a manner that only gets us pass the next pr.
I think we really do need to deal with it on a per pass basis. We occasionally get a monster PR which shows half a dozen (or more) serious time hogs. We more often get a pathological case for a specific pass. In each and every one of these cases, someone has taken a look at how to improve the time hog(s). Usually the result is a leaner/faster and improved pass, although it sometimes takes a new release for it to happen :-). Occasionally, we turn something off. A couple of PRs with massive functions are primarily responsible for the pending changes to out-of-ssa... And those changes will benefit small functions as well as the large ones. If we start throttling some of these passes simply because a big function is coming through, we are likely to miss out on some of these further improvements triggered by large functions. Another reason I favour per-pass is because there may very well be throttling options available which don't completely turn off the pass. There may still be useful things that can be done with less precise information for instance... Only the individual pass can properly make that decision. I think the effort put into a pass manager would be better put into the passes themselves. And any time a pass is actually throttled, it should be well documented as to why it is being throttled, the PR/testcase which is causing it to be throttled, and ideas/suggestions for changes in the future which will allow it to become un-throttled. When we start a new release, someone could take a quick visit to each of these throttled passes and see if there are any proposed projects to help with them. Encourage these types of projects, maybe even disable all throttling in stage 1. And finally, maybe in stage 2, take a quick run through and see if the throttling is still necessary. Perhaps other infrastructural changes have helped some, and the throttling decision needs to be changed. I think its important we not throttle-and-forget optimizations. Andrew
