This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SoC Project: Incremental Parsing (of C++)
On Mar 20, 2007, at 8:13 PM, Simon Brenner wrote:
Wow, lots of comments there, Mike ;-)
I could say a lot more... I thought I'd let you drag any other
details you wanted out of me. :-)
My idea was to initially just check for any not obviously safe
changes, and later in the project try to determine the most important
kind of changes to handle intelligently. That is, a change would be
considered dangerous until proven safe. But I guess I might find that
almost nothing at all can be done without that fine-grained checking.
We went the other way, assumed safe, then, test out things we know
are dangerous and put in code to handle it, and build projects and
find things that needed more work.
Would it be possible to calculate the dependencies from the tree of a
function?
Yes, if you annotate the tree with all the information necessary to
do this.
In the worst case, you'd just keep on going naively, crash, and let
the build script retry a non-incremental compile.
We did this as well, restart the server on crash and then retry.
Which of these are only of importance when doing code generation?
Of that list, RTX constant pools, debugging information, exception
tables, I'd expect.
How good did you manage to get the compile server in terms of
fidelity?
One medium C++ app worked for one port, though that might have been
around 2% of all the features. For example, I have to be able to
have machine ports be able to replay state changes, I did some of
those for one OS, one target. gcc has many such configurations. If
50, I hardly did 1/50 of all the work with the one port.
I'm happy to forego the extra gains
That would avoid one problem we faced.
Trying to do all these things at once is probably a contributing
factor to the compile server not being in the mainline.
Agreed.
Anyways, how far did the compile server go?
One medium C++ project (Finder_FE) on one platform.
What was left to do when development stopped?
I think it boils down to just more language fidelity. Other things
could be done, like, distribute to other hosts, ensure we don't run
out of ram or vm, and replay support for all the rest of the ports,
but, I don't think these would need to have been done before the
first checkin to mainline with the feature off by default.
And why did development stop?
I'd guess that if you asked three people, you'd get three
answers. :-) I think it boils down to death by branch. Just too
much work left to do, no way to deliver a release quality compiler
without spending the time doing all the rest of the work. If we
choose the design point of keeping perfect language fidelity at all
times, and could check in to mainline as it was developed without
having to spend three weeks for each 5 line change, we might have
been able to eek out a compiler that was significantly faster by now.
We're still interested in advanced technologies to get a compiler
that is 2-4x faster. Would like to see buy in for how we get that
and in what direction we should all move to get it, set and agreed
upon for the project. The people can work against it as they can,
and hopefully in the end, we'd get were we want to go.