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

Cache const eval queries #48864

Merged
merged 2 commits into from
Mar 14, 2018
Merged

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Mar 9, 2018

fixes #48846 (I think, still running more perf tests, but tuple-stress stops recomputing any constants)

r? @michaelwoerister

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 9, 2018
@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 9, 2018

@bors try

(we should run real perf tests first I guess)

@bors
Copy link
Contributor

bors commented Mar 9, 2018

⌛ Trying commit 34e40835466881add360ade69d2c1be23ddc2cb5 with merge 1096950c850a1c21d1e8a5b1caf6593da10997bf...

@bors
Copy link
Contributor

bors commented Mar 9, 2018

☀️ Test successful - status-travis
State: approved= try=True

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 9, 2018

ping @simulacrum can you run a perf test?

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 9, 2018

hmm... while this works and passes tests, it can cause AllocIds for statics to exist without a corresponding Allocation when running with incremental, which causes an ICE.

@Mark-Simulacrum
Copy link
Member

Perf started for 1096950c850a1c21d1e8a5b1caf6593da10997bf.

@oli-obk oli-obk force-pushed the miri_incremental_regression branch from 34e4083 to 6cdc8cf Compare March 9, 2018 13:24
@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 9, 2018

Okay. I figured it out. incremental caches only works for queries that take a single DefId. You can get the query to get serialized, but the inverse won't work (and there's no compile-time error 😢 ).

So now I implemented it from scratch.

@oli-obk oli-obk force-pushed the miri_incremental_regression branch 2 times, most recently from 4e566ec to e2a3754 Compare March 12, 2018 10:00
@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 12, 2018

This should now improve incremental builds compared to pre-miri. Not just undo the regression.


#[inline]
fn cache_on_disk(key: Self::Key) -> bool {
key.value.instance.def_id().is_local()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can non-local consts be loaded from metadata? Otherwise we just might want to cache everything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not yet (at least not in general, some are), but it is planned

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just return true here then.

@@ -223,6 +231,45 @@ impl<'sess> OnDiskCache<'sess> {
encode_query_results::<trans_fn_attrs, _>(tcx, enc, qri)?;
}

// encode successful constant evaluations
let constants_index = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great if we had a comment (here or elsewhere) explaining why constants even need special handling (like you did on IRC).

@michaelwoerister
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Mar 12, 2018

⌛ Trying commit e2a375426584ebaa8359d598a9ea947057a539eb with merge a04ce41981aa3b98cd562106e77e2a7c0761883c...

@bors
Copy link
Contributor

bors commented Mar 12, 2018

☀️ Test successful - status-travis
State: approved= try=True

@michaelwoerister
Copy link
Member

@Mark-Simulacrum, could you do a perf-run please?

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 13, 2018

We could reuse the regular caching strategy, if either

  • we don't cache const_eval queries that resulted in an error (which does not necessarily result in a reported error!, so we might end up redoing some work in the next compilation)
  • we don't serialize the error enum and instead pull a dummy variant from the ether during deserialization (does this cause problems with hashing/equality expecting the same value after deserialization?)

The reason for this is that serializing/deserializing the error enum is a huge mess... We'd need to serialize things like ty::Layout and others, because the error variants contain such types.

@Mark-Simulacrum
Copy link
Member

Perf should be queued.

@michaelwoerister
Copy link
Member

We could reuse the regular caching strategy, if (...) we don't cache const_eval queries that resulted in an error

That sounds fine to me but how is it related to the problems with statics that we talked about yesterday? Is this an additional problem?

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 13, 2018

That sounds fine to me but how is it related to the problems with statics that we talked about yesterday? Is this an additional problem?

I'd change statics to always return ByRef instead of ByVal, so they contain an AllocId to their allocation. Simple constants will stay ByVal. Since the query caching will then cache the ByRef, it'll also trigger a serialization for the AllocId.

I don't think anyone is reading the value of statics at compile time atm other than const eval itself, so having it ByRef is fine. This is only a convenience feature for reading the constant's value, there's no disadvantage other than that accessing a ByRef constant requires a bunch of function calls instead of just matching on the value.

@oli-obk oli-obk force-pushed the miri_incremental_regression branch from e2a3754 to 0d88db1 Compare March 13, 2018 15:24
@michaelwoerister
Copy link
Member

OK, sounds good!

@Mark-Simulacrum, I think that perf-run is unfortunately obsolete then.

@michaelwoerister
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Mar 13, 2018

⌛ Trying commit 0d88db1 with merge 0209427...

bors added a commit that referenced this pull request Mar 13, 2018
Cache const eval queries

fixes #48846 (I think, still running more perf tests, but tuple-stress stops recomputing any constants)

r? @michaelwoerister
@bors
Copy link
Contributor

bors commented Mar 13, 2018

☀️ Test successful - status-travis
State: approved= try=True

@Mark-Simulacrum
Copy link
Member

Perf queued.

@oli-obk
Copy link
Contributor Author

oli-obk commented Mar 14, 2018

Style servo regressed in clean incremental, but not in patched incremental. Weird. I probably won't get to investigate this before monday

Everything else gained compared to before miri. Now there are mostly regular compile-time regressions, not incremental regressions.

@ishitatsuyuki
Copy link
Contributor

@oli-obk servo style clean-incr regression is known to be spurious; you can check the graph and it's widely fluctuating.

@michaelwoerister
Copy link
Member

OK, I think we should merge this version.

@eddyb, would you mind taking a look at the const evaluator changes?

@eddyb
Copy link
Member

eddyb commented Mar 14, 2018

@bors r+

@bors
Copy link
Contributor

bors commented Mar 14, 2018

📌 Commit 0d88db1 has been approved by eddyb

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 14, 2018
@kennytm
Copy link
Member

kennytm commented Mar 14, 2018

@bors p=1

Slightly bumping performance improvement PRs.

bors added a commit that referenced this pull request Mar 14, 2018
Cache const eval queries

fixes #48846 (I think, still running more perf tests, but tuple-stress stops recomputing any constants)

r? @michaelwoerister
@bors
Copy link
Contributor

bors commented Mar 14, 2018

⌛ Testing commit 0d88db1 with merge 11d9959...

@bors
Copy link
Contributor

bors commented Mar 14, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 11d9959 to master...

@bors bors merged commit 0d88db1 into rust-lang:master Mar 14, 2018
@oli-obk oli-obk deleted the miri_incremental_regression branch June 15, 2020 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

50-110% compilation time regressions due to miri
8 participants