[cfe-dev] distributed clang patch

Csaba Hruska csaba.hruska at gmail.com
Thu Jul 10 17:36:23 PDT 2008


2008/7/11 Ted Kremenek <kremenek at apple.com>:

>
> On Jul 10, 2008, at 4:56 PM, Csaba Hruska wrote:
>
>  This looks for me a completly different project called: integrating clang
>> preprocessor to (original)  distcc because except the used preprocessor
>> remains the original (command line options, network protocol and the whole
>> functionality). This is not bad but i dont think that this is the primary
>> task of this project. In my opinion the main goal to make as fast and
>> scalable and portable(support crosscompialtion) compiler as we can using
>> clang.
>>
>
> Of course our interest is making a great distcc for clang.  My main
> meta-point was that by supporting other compilers for subtasks of the
> compilation work you can stage more of the implementation without relying on
> everything in Clang to be working perfectly.  And despite Argiris great work
> on C++ parsing, full support for C++ compilation is a long way off, so
> supporting other compilers for this task might be a huge win for adoption of
> a new distcc.
>
> Also, it's better to get measurements early on where the performance issues
> are because that effects fundamental aspects of the design.  A rapid
> evolution of the distcc design with testing and real numbers will not only
> make the new distcc both faster and more scalable (per your goals) but also
> potentially more stable and usable at an earlier stage.
>
I agree that benchmarking is important to find the weak design points and
I'm also curious about performance results. I'll do some benchmark after
when i finish the astconsumer lib and get the new driver code.  My main
problem is that I cant imagine how we can support external compilers without
messing up the current design and without reimplement the original distcc.
Distributed clang server's goal is support compilation natively without
executing external programs. Or if you think to support the client side,
(new clang distcc client with original distcc server case) then we have to
reimplement distcc's protocol, including ssl support. In this case its far
much easy to patch the original distcc client to include and use clang's
preprocessor natively.
I'd like to focus on clang specific stuff. Ex: I can imagine an AST mege
function what can support precompiled headers, or can be used to store the
already parsed and semachecked headers and reuse it later from a Database.
This means one file (header) is parsed and semantically checked only one
time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080711/310afb30/attachment.html>


More information about the cfe-dev mailing list