On Mon, 19 Mar 2012 13:26:00 +0000 Andrew Haley <a...@redhat.com> wrote:
> On 03/18/2012 11:53 PM, Tomasz Borowik wrote: > > > The perfect solution would be to shun away the standard model and > > actually support a kind of on-demand recompilation where the editor > > tells the compiler (running in background) what has changed and the > > compiler (having a function inlining map) recompiles only the > > necessary pieces and replaces them in the elf files. Though that's > > probably too far-fetched (there's also the question of how much of > > gimple/generic could be kept between recompilations). > > > Simplifying we skip the "working in background" and the last step, > > and just generate separate .s files, I've almost hacked this but I > > had a lot of trouble with missing or duplicate variables/labels etc. > > http://www.gccsummit.org/2003/view_abstract.php?talk=28 > > Andrew. Thanks, I got "Could not connect to database server." but found it at: http://per.bothner.com/papers/GccSummit03-slides/index.html and I also found a more recent attempt: http://gcc.gnu.org/wiki/IncrementalCompiler That gave me an idea on how to improve my current hack without too much effort, which should save me quite a bit of time on recompiling until I write something better;) Now if I were to tackle this I'm affraid I probably wouldn't be touching the C or any other front-end (appart from my own). That just seems like way too much work, and the issues that might come up with preprocessing, lexing, parsing and build systems are quite scary. The case with my language is quite different as I'm usually working with one or a few very large files (and lots of system headers), so I'm mostly interested in recompiling a given file at the smallest granularity that makes sense (right now it's about 20 functions) rather than deduplicating work between files. The editor can supply any information I wish, so there is no need to figure out what changed within the driver and/or compiler. Unfortunately that seems to slightly diminish the benefit of any such work for other of languages and the world. On the other hand this would have a fairly deep connection with all the "modularity" efforts. I dislike the vagueness of the term quite a bit (and the flame war that seems to be brewing on it). So my work might include any or all of (unfortunately almost as vague) tasks: - documenting the method of building GENERIC and passing it to the middle-back-end along with some options, the output file, getting back the inlining info - making sure the middle-back-end can be reinitialized for processing potentially completely different code with different options, output file, and documenting how to do it - documenting the requirements put on GENERIC by the middle-back-end and whether/how it modifies it, and possibly eliminate those, - making the middle-back-end thread safe (global variables are not necessarily wrong if they are in tls and there are functions that handle launching the threads). >From what little experience I've had the interface between the front-end and >the rest seems very unclear, and kind of reversed where toplev.c is the driver >and the frontend just provides some hooks, wheras it seems to me it should be >the frontend in control and using some libraries/modules/whatever to handle >common tasks like option parsing, initializing/launching middle-back-end work, >and any other stuff. At least that would make creating the kind of compiler I'm aiming for much easier. Tomasz "timon" Borowik
