Re: incremental compiler project

[Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>]

On 4 September 2015 at 17:11, 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.

But we don't even know why it is so slow, no? (Or perhaps it is
known:https://gcc.gnu.org/wiki/Speedup_areas#C.2B-.2B-_improvements
but no one has decided to fix them)

Clang++ is much faster yet it is doing more and tracking more data
than cc1plus. Thus, there have to be things that can be optimized in
the C++ parser. For example, we know that by-passing the textual
assembler representation has to speed-up compilation
(https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00188.html), specially
for large programs (simply printing it more efficiently already leads
to measurable speed-ups:
https://gcc.gnu.org/ml/gcc/2011-06/msg00156.html).

> On the other hand, I'm not sure the incremental compiler is the way to
> go.  It is a complicated approach.

Perhaps libcc1 could be re-purposed for this? It allows inserting code
into an already existing binary. Perhaps it could allow replacing code
from it? I have only a nebulous idea of how libcc1 works, maybe this
does not make any sense.

> 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.

Probably yes. Unfortunately, I don't know of any plans to implement
this in any form (much less for C).

Cheers,

Manuel.