Re: Thoughts on LLVM and LTO

[Daniel Berlin <dberlin at dberlin dot org>]

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.