> (B) What bits of GCC would we be bypassing, and how badly would we miss > them? > > Presumably, many of the shiny new tree optimizers. Ow. But GCC was > not in any state to do this sort of surgery a year ago, I think. > Probably true on both counts, but that wouldn't bother me, speaking as someone who has written a lot of code for the tree optimizers.
The tree optimizers serve a purpose, they are not a goal unto themselves. If LLVM can serve that purpose, and do so better (or can be made to do so better by moving improvements, extending it), while at the same time bringing us other benefits, then the correct technical decision is to move to it and replace the tree optimizers. Realistically, we are going to end up doing as much surgery on the GIMPLE and SSA representation (in terms of underlying data structures, aliasing, re-writing and re-tooling optimizers, etc) in order to make IPA work well, that 1. It will probably be same amount of work (if not less work) to move the improvements we have *to* LLVM, as all the surgery is going to take to make IPA sane in GCC. The only real difference is in what work you are doing. Building it from scratch may seem intellectually cool or whatever, but from a technical standpoint, you aren't going to end up with an infrastructure significantly better than LLVM's infrastructure is or could be extended to be. This is because anybody who has looked at compilers that have really good IPA will tell you that you realistically can't do better in terms of compile speed or memory usage, and that there is no magic that we could perform that we can't make LLVM perform. 2. LLVM is here and we know it works, plus we know it's memory usage and compile time on various applications. All *we* have is guesses on how much memory and compile time we can save based on what kind of surgery you want to perform. We have some idea for what it would take to make IPA work well, and the rest is just expected to "become clear" as things progress. The bottom line is that personally, I'm not in love with tree-ssa or my code enough that I think ego should stand in the way of GCC making the right decision. I would hope others who have written the "shiny new tree optimizers" feel the same way. I'd be just as happy moving data dependence, aliasing improvements (that aren't subsumed by DSAA, which there are still plenty of :P), high level loop transforms, better PRE, etc, from GCC to LLVM, as i would re-tooling it to work with whatever we came up with from scratch. GCC has a lot of hard work ahead of it, whether we choose to build it from scratch and do major surgery. The question is whether you want to take what we know works, or roll the dice and hope you can make something better. Unless y'all think you are going to get really lucky, and do something nobody has been able to do yet, integrating LLVM is, IMHO, a sound technical decision, even if it means replacing the tree optimizers. Just my 2 cents, Dan
