Vladimir N. Makarov wrote: > The ORC backend optimizations proven to work for Itanium could be > rewritten for RTL with usage of existing gcc infrastructure, added to > gcc and could be used for other ports. I think it is more right way to do.
I strongly agree, except that I would generalize "RTL" to "tree-ssa and RTL". In fact, I have personally encouraged some of the people involved in this new effort to approach the problem from the point of view of taking the best of the ORC algorithms and incorporating them into GCC, rather than trying to get the community to switch to the ORC back-end. I've advocated that position for several years, to some of the key decision-makers, including as recently as a couple of weeks ago. I've been told by at least some ORC people that the long-term plan is to do as I've suggested, but that they can't do it in the short term. >From my conversations, I've been lead to think that there are two considerations that are causing the ORC people to want to stay separate. The first is that they believe that the ORC performance on the target platforms of interest is sufficiently better than FSF GCC that their time-to-solution using ORC is quicker than using GCC. I don't know how to counter this point, as it may very well be true. I've made the long-term argument about maintenance, forking, support for many architectures, etc., but I was told that time-to-solution is the paramount consideration. There are plausible business reasons for the parties involved to feel that way. The second is a not-invented-here attitude towards trees and RTL. Some ORC people claim that WHIRL is *so* much better than trees/RTL that things just can't be fixed tractably in GCC. I disbelieve this argument; I think it's similar to saying that you can't write good code in TCL. I don't disbelieve that WHIRL has advantages, but I do disbelieve that those advantages are so great, or that GCC's IR is so inherently bad, that GCC's optimizers are truly an unsatisfactory place to start. In summary, I think that splitting GCC optimization efforts between FSF and ORC back-ends is unfortunate. I would far rather that the free software community be united behind a single optimizer. But, fundamentally, I don't see much that we can do about it -- unless someone is sitting on a patch for making Itanium performance dramatically better. I think the best that we can do is to try to help identify what it is that makes ORC perform better and adopt those same strategies for FSF GCC. I'm happy that we're collectively spending a lot of time looking at benchmark performance. I think that, for good or ill, SPEC numbers are incredibly important to people. Making those numbers good is a key aspect of making FSF GCC competitive. I'm not suggesting we ignore "real" code, but I am suggesting that benchmark performance is one of the ways GCC is going to be judged, and that we should care about that. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
