On Tue, Nov 22, 2005 at 11:20:02AM -0500, Diego Novillo wrote: > If we choose LLVM, I have more questions than ideas, take these thoughts as > very preliminary based on incomplete information: > > The initial impression I get is that LLVM involves starting from scratch. > I don't quite agree that this is necessary. One of the engineering > challenges we need to tackle is the requirement of keeping a fully > functional compiler *while* we improve its architecture.
Most of your concerns seem to be based on this impression; I don't think it's right. I'll keep this brief since others can probably answer the details more accurately than I can. LLVM as a backend, i.e. replacing everything from GIMPLE -> assembly, would involve a lot of starting from scratch. e.g. your later example of limited target support. One of the options Chris proposed is an optional GIMPLE -> LLVM -> GIMPLE process, in which: (A) the LLVM step is only necessary for optimization - I like this for lots of reasons, not least being that we could bootstrap without a C++ compiler. (B) the LLVM register allocator, backend, et cetera would be optional or unused, and the existing GCC backends would be used instead. Which are there today, need some modernizing, but work very well. The LLVM -> GIMPLE translator does not exist yet; I believe Chris has a prototype of the GIMPLE -> LLVM layer working, and it took him under a month. I've been convinced that the opposite direction would be as straightforward. That's something a sufficiently motivated developer could hack out in the course of this discussion. > From what I understand, LLVM has never been used outside of a research > environment and it can only generate code for a very limited set of > targets. These two are very serious limitations. LLVM is indeed very new. At this point I believe it has been used outside of a research environment, but I can't say how thoroughly. > Finally, I would be very interested in timelines. Neither proposal > mentions them. My impression is that they will both take roughly the same > amount of time, though the LLVM approach (as described) may take longer > because it seems to have more missing pieces. I'd have guessed the other way around; the GVM/LTO proposal is for a completely new technology and the LLVM proposal is for merging an existing (already GCC-based) technology to work more closely with GCC. I'm not actually as biased in favor of LLVM as this message sounds; I feel that I don't have a good enough understanding of either option. But I wanted to clarify what I've learned from my earlier conversations about this topic. -- Daniel Jacobowitz CodeSourcery, LLC
