This is the mail archive of the
mailing list for the GCC project.
Re: incremental compiler project
- From: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: David Kunsman <dmkunsman at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 4 Sep 2015 17:57:17 +0200
- Subject: Re: incremental compiler project
- Authentication-results: sourceware.org; auth=none
- References: <CAPVyUPD0eAyAuPOktpjqpY=UKx0t2YEvFQxMUMY2Lv2pwUAjLA at mail dot gmail dot com> <55E87708 dot 7010901 at gmail dot com> <87twrap6c2 dot fsf at tromey dot com>
On 4 September 2015 at 17:11, Tom Tromey <email@example.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
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
for large programs (simply printing it more efficiently already leads
to measurable speed-ups:
> 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).