I’ve said this before, but I think a major impediment to forward progress here is coming up with an agreement on what the “something else” should be. Some of us have talked for years about having some TableGen-driven replacement, or maybe we want something with a syntax more like what is used by the Alive tool, but regardless, in order to gain in efficiency I suspect we need a model that is more restrictive than more-or-less arbitrary C++ code, and so we should pick a model and figure out how things might work. This also matches my experience, but I draw a somewhat different lesson. I often tell application developers that this is why they must file compiler bug reports. Waiting and assuming that someone else will hit the same problem, and file the report, is a bad strategy. I think that this is due to two things: 1. As far as things go, the tail of the distribution is often really long, and probability that the particular thing hampering one piece of hot code is the same thing hampering another piece of hot code is often small. 2. We tend to add special cases instead of adding more-general algorithms. The more-general work is often hard because figuring out the cost modeling is often highly non-trivial. Also, when it’s finally done, the chances that the old special cases are removed is also small (so we’ll still accumulate cruft without specific effort).
My experience is also exactly like this. We keep adding new patterns to inst-combine, but nothing has been done yet to modularize or somehow partition it to reduce the costs we need to pay for these new patterns. Inst-combine is scheduled to run 8 times in the current O2/Os pipelines and 9 times in O3. In most applications the new patterns will probably never even trigger, but we will check for them at least 8 times. It’s more or less acceptable for O3, where we’re supposed to try squeezing as much optimizations as possible, but for O2 and Os it doesn’t sound reasonable to me.
Recently AggressiveInstCombine pass has been added and probably some of the patterns might go there to slightly reduce the costs, but a bigger rethink might be needed in this area anyway. I’d be glad to help doing this if we agree on a general direction we want to go.
Michael