On Sun, 2005-11-27 at 11:58 -0800, Devang Patel wrote: > > > > > > With our limited resources, we cannot really afford to go off on a > > > multi-year tangent nurturing and growing a new technology just to add > > > a > > > new feature. > > > > > What makes you think implementing LTO from scratch is different here? > > I read entire thread (last msg, I read is from Mike Stump) but I did not > see any discussion about productivity of GCC developers. > > If one approach provides tools that make developer very very productive > then it may blew initial work estimates out of water. > > Here are the questions for LLVM as well as LTO folks. (To be fair, > Chris gave us some hints on few of this, but it is OK if people ask him > for clarifications :) And I have not read anything about this in LTO > proposal, so I take that this may need extra work not considered in > LTO time estimates). > > 1) Documentation > > How well is the documentation so that _new_ compiler engineer can > become productive sooner ?
There is no question that LLVM has much better documentation of IR and semantics than we do, See, e.g., http://llvm.cs.uiuc.edu/docs/LangRef.html It has tutorials on writing a pass, as well as example passes, http://llvm.cs.uiuc.edu/docs/WritingAnLLVMPass.html > > 2) Testability of optimization passes > > How much precision one can get while testing particular feature, > optimization pass? You can run one pass at a time, if you wanted to, using opt (or two, or three). > > 3) Integrated tools to investigate/debug/fix optimizer bugs bugpoint beats pretty much anything we have, IMHO :). > > 4) Basic APIs needed to implement various optimization techniques All the basics are there for scalar opts. There is no data dependence yet, but they have a fine working SCEV, so it's only a few months to implement, at most.
