Re: incremental compiler project

[David Kunsman <dmkunsman at gmail dot com>]

what do you think about the sub project in the wiki:

Parallel Compilation:

One approach is to make the front end multi-threaded. (I've pretty
much abandoned this idea. There are too many mutable tree fields,
making this a difficult project. Also, threads do not interact well
with fork, which is currently needed by the code generation approach.)

This will entail removing most global variables, marking some with
__thread, and wrapping a few with locks.

For the C front end, sharing will take place at the hunk level. The
parser will acquire a lock on a hunk's key before parsing (or
re-using) the hunk. Once the hunk has been registered the lock will be
released. This will allow reasonably fine-grained sharing without
possibility of deadlock.

This sub-project will also require updates to the GC. The current plan
is to have ggc_collect be a safe point; this works well with the C
parser as it collects in each iteration of the main loop. The C++
parser does not do this, and will need to be modified. Additionally,
the server main loop will either need not to hold GC-able data, or it
will need a way to inform the GC of its activity. (Note that the GC
work is completed on the branch. The C++ parser has not been modified
to periodically collect, however.)

?

On Fri, Sep 4, 2015 at 10:11 AM, Tom Tromey <tom@tromey.com> wrote:
> Manuel> The overall goal of the project is worthwhile, however, it is unclear
> Manuel> whether the approach envisioned in the wiki page will lead to the
> Manuel> desired benefits. See http://tromey.com/blog/?p=420 which is the last
> Manuel> status report that I am aware of.
>
> Yeah.  I stopped working on that project when my manager at the time
> asked me to work on gdb instead.
>
> I think the goal of that project is still relevant, in that C++
> compilation is still just too darn slow.  Projects today (e.g., firefox)
> still do the "include the .cc files" trick to get a compilation
> performance boost.
>
> On the other hand, I'm not sure the incremental compiler is the way to
> go.  It is a complicated approach.
>
> Perhaps better would be to tackle things head on; that is, push harder
> for modules in C and C++ and fix the problem at its root.
>
> Tom