Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hash partition contents and compare again hashes from previous efforts #34037

Closed
nikomatsakis opened this issue Jun 2, 2016 · 0 comments
Closed
Labels
A-incr-comp Area: Incremental compilation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

For each partition, we need to hash its contents (the symbol names of the items it contains, basically) and save them. Then, in the next compilation, we will recompute the partitions, rehash the contents, and compare against the previous hashes (alternatively, we could just save the list of symbol names). This will allow us to determine if the contents of a partition have changed from the previous compilation.

Note: an alternative would be to use the dependency graph edges to determine when a partition is invalidated. Basically we would create dep-nodes representing the partition map and so forth. However, we decided not to do this because the resulting graph would be quite coarse and not effective in practice without manual intervention. For example, when computing the partitioning, we enumerate all the items, which means that we wind up tracing from a function F to its callees. However, if the body of one of those callees changes, it does not imply that the partition containing F would (necessarily) need to be rebuilt. Moreover, just adding edges after the fact is a bit tricky, since we have to be careful that if new items are added to the partition, we will regenerate it.

So TL;DR it seems simplest to always regenerate the partitions and then compare the results.

cc @michaelwoerister

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-incr-comp Area: Incremental compilation labels Jun 2, 2016
@nikomatsakis nikomatsakis added this to the Incremental compilation alpha milestone Jul 23, 2016
bors added a commit that referenced this issue Jul 28, 2016
Enable reuse of `.o` files if nothing has changed

This PR completes a first "spike" for incremental compilation by enabling us to reuse `.o` files when nothing has changed. When in incr. mode, we will save `.o` files into the temporary directory, then copy them back out again if they are still valid. The code is still a bit rough but it does seem to work. =)

r? @michaelwoerister

Fixes #34036
Fixes #34037
Fixes #34038
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

1 participant