RFC: Support Incremental Compilation #594
Conversation
There was a problem hiding this comment.
Hash the relevant flags for the subdir name? I'd expect a lot of -C options affect the cache, and only storing one set wouldn't help at all for some usage patterns.
There was a problem hiding this comment.
Yeah, something like that. I'd like to see how big such a cache gets.
|
cc @epdtry who implemented most of a very similar scheme last summer. We talked about this as incremental codegen (as opposed to proper incremental compilation). He only kept around object files, not llvm ir too. It would be great if @epdtry could link to his WIP branch and explain the concepts, etc. here. |
There was a problem hiding this comment.
We already can do codegen in parallel, although there is a bug preventing most use atm.
|
Please don't make the acronym |
|
I agree with @dhardy. As an alternative, may I propose "So Far, Incrementalism Necessitates An Exegesis"? |
|
@dhardy |
There was a problem hiding this comment.
On the subject of monomorphized identifiers: you'll probably need to do something about symbol naming for monomorphizations of functions. Right now the name includes the hash of the pointers to the Tys representing the type arguments (which is random, thanks to ASLR). This does fine at preventing collisions, but it means you'll need to either record the mapping of (polymorphic function, type arguments) -> (symbol name) for use in later incremental builds, or fix symbol naming to produce something consistent. I tried to do the latter, but it wound up being a little more complicated than I expected (ADT Tys reference the struct/enum definition by its DefId, which is not stable) and I don't remember if I ever got it working.
There was a problem hiding this comment.
Yes, that's a problem. I'd probably try to find a more stable symbol naming scheme.
|
I am expanding and adapting this RFC. After some discussion with @michaelwoerister we decided to close this existing PR for the time being. |
This RFC proposes an incremental compilation strategy for
rustcthat allows for translation, codegen, and parts of static analysis to be done in an incremental fashion, without precluding the option of later expanding incrementality to parsing, macro expansion, and resolution.This RFC is purely about the architecture and implementation of the Rust compiler. It does not propose any changes to the language. I also don't expect it to be acted on any time before 1.0 is out of the door, but I wanted to get this out into the open, so that it can discussed as part of the RustC Architecture Improvement Initiative (that's right, RAII) that I invented just now and that will begin to discuss how the Rust compiler can get as good as possible once the language has become a more stable target.
Rendered