[cfe-dev] my gsoc proposal: llvm/clang distcc

[Steve Naroff]

Peter,

Developing an AST-centric caching mechanism is very interesting.

Last time I looked at distcc, it basically preprocessed the file  
locally and sends the result to distributed nodes. The benefit of this  
approach is it's very simple (no dependencies on headers, macros, etc.).

That said, caching AST's will require more "smarts" than distcc (in  
many ways). Knowing if an AST can actually be reused across module  
boundaries is a little tricky (given the flexibility of the  
preprocessor and mutable headers). I co-authored NeXT's first pre- 
compiled headers scheme which actually implemented sharing/checking.

Another point...I think the notion of caching AST's locally (on a  
single machine) is also interesting (and possibly more useful than  
traditional pre-compiled header schemes, where the developer needs to  
fiddle with defining a huge header to make the compiler fast).

snaroff


On Apr 7, 2008, at 11:07 AM, Peter Neumark wrote:

> Hi,
> As far as I know, distcc doesn't support binary AST caching and  
> distribution.
> And the proposal is about complete reimpementation in C++ with  
> static linked llvm/clang libs.
> The main benefit is in handling (storing, caching) AST-s in binary  
> form. And also to have a central process, which
> tracks the node network load and coordinates incoming tasks  
> according it.
>
> On Mon, Apr 7, 2008 at 7:47 PM, Eric Christopher  
> <echristo at apple.com> wrote:
> Hi Peter,
>
> I've taken a look at this proposal. Can you say how this is  
> different than either a) modifying dcc_find_compiler to use clang as  
> an option or b) saying distcc clang for compilation?
>
> Otherwise it looks like a simple change to distcc and not clang at  
> all. Unless you were planning on reimplementing distcc for clang?
>
> -eric
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080407/982633f6/attachment.html>