Turn const eval queries into canonical queries #67717
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
Centril
reviewed
Dec 30, 2019
Centril
added
the
A-lazy-normalization
This comment has been minimized.
This comment has been minimized.
BenLewis-Seequent
force-pushed
the
canonicalize-const-eval
branch
from
aa821a8
to
2afeac9
Compare
|
☔ The latest upstream changes (presumably #67853) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I spent time on Friday reviewing this, will finish up on Monday |
varkor
reviewed
Jan 6, 2020
|
Presumably this comment can also be removed now: Lines 2399 to 2400 in 8f94d9b |
|
This doesn't fully resolve that comment, as |
nikomatsakis
approved these changes
Jan 6, 2020
| | ty::Predicate::ClosureKind(..) | ||
| | ty::Predicate::ConstEvaluatable(..) => true, | ||
| ty::Predicate::TypeOutlives(..) | ty::Predicate::RegionOutlives(..) => false, | ||
| } |
There was a problem hiding this comment.
Why are we filtering these bounds?
There was a problem hiding this comment.
This was an initial hack to remove inference variables from the param_env before calling subst_and_normalize_erasing_regions. I since replaced that in a later commit with infcx.at(..).normalize(..), which dies handle inference variables.
| /// Stores the `Machine` instance. | ||
| pub machine: M, | ||
|
|
||
| /// The results of the type checker, from rustc. | ||
| pub tcx: TyCtxtAt<'tcx>, | ||
|
|
||
| pub(super) infcx: &'infcx InferCtxt<'infcx, 'tcx>, |
There was a problem hiding this comment.
Do we use this field for anything?
There was a problem hiding this comment.
Yes we do, for normalizing, Instance::resolve_xxx calls, and recursive const_eval queries. We need to use this whenever we pass param_env into a query as it can contain inference variables.
There was a problem hiding this comment.
Why do we use inference variables? Couldn't miri be executed with the canonical form?
Canonical variables in scope would behave like type parameters, wouldn't they?
There was a problem hiding this comment.
Hm, I never thought about that, I don't think we actually need inference variables as we aren't actually resolving them. Currently it seems like the canconical form is only ever used in preparing/start of queries, so I'm not sure what problems would there be like what happens to Bound variables if they are part of a canonical query down the line.
It would certainly make InferCtxt less invasive, which seems like a good thing. I would like to hear @nikomatsakis thought on this.
There was a problem hiding this comment.
I don't really see a problem with it.
|
This all looks "basically right" to me. Obviously, it needs to be rebased. I'm wondering also whether we should test performance -- seems like maybe yes? |
inference context into mir execution context.
allow param env to contain inference variables.
`resolve_vtable`.
…gions.rs` so that it's not weirdly on it's own within the codegen module.
…me lifetime parameters.
BenLewis-Seequent
force-pushed
the
canonicalize-const-eval
branch
from
2afeac9
to
92b63b8
Compare
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
bors
added a commit
that referenced
this pull request
Jan 7, 2020
Turn const eval queries into canonical queries This is ground work for lazy normalization of consts. This enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection. r? @nikomatsakis
|
☀️ Try build successful - checks-azure |
|
Queued 952f90b with parent 4f074de, future comparison URL. |
|
Finished benchmarking try commit 952f90b, comparison URL. |
RalfJung
reviewed
Jan 7, 2020
| /// Stores the `Machine` instance. | ||
| pub machine: M, | ||
|
|
||
| /// The results of the type checker, from rustc. | ||
| pub tcx: TyCtxtAt<'tcx>, | ||
|
|
||
| /// The inference context for inference variables that are within this `InterpCx`. Inference | ||
| /// variables may be within either the `param_env` or within `substs` of frames. Many operations | ||
| /// outside of mir which takes values that may contain variable require this context. |
There was a problem hiding this comment.
Suggested change
| /// outside of mir which takes values that may contain variable require this context. | |
| /// outside of mir which take values that may contain variable require this context. |
Also, what is "outside of mir"?
And -- does this basically mean we have to use this (one way or another) whenever we use param_env or a frame subst?
|
This results in many more queries being invokes in clean incremental builds. |
bors
added a commit
that referenced
this pull request
Jan 11, 2020
perf: Eagerly convert literals to consts Previousely even literal constants were being converted to an `Unevaluted` constant for evaluation later. This seems unecessary as no more information is needed to be able to convert the literal to a mir constant. Hopefully this will also minimise the performance impact of #67717, as far less constant evaluations are needed.
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Jan 14, 2020
perf: Eagerly convert literals to consts Previousely even literal constants were being converted to an `Unevaluted` constant for evaluation later. This seems unecessary as no more information is needed to be able to convert the literal to a mir constant. Hopefully this will also minimise the performance impact of rust-lang#67717, as far less constant evaluations are needed.
bors
added a commit
that referenced
this pull request
Jan 15, 2020
perf: Eagerly convert literals to consts Previousely even literal constants were being converted to an `Unevaluted` constant for evaluation later. This seems unecessary as no more information is needed to be able to convert the literal to a mir constant. Hopefully this will also minimise the performance impact of #67717, as far less constant evaluations are needed.
|
Would it make sense to rebase and do another perf run now that #68118 is merged? |
|
Sounds good to me! |
|
Waiting for discussion on whether we can just use the canonical form instead of introducing |
@Skinny121: It looks like that should work, if I understand the linked discussion. |
bors
added a commit
that referenced
this pull request
Feb 28, 2020
…komatsakis Canonicalize inputs to const eval where needed Canonicalize inputs to const eval, so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection. This is a reattempt of #67717, in a far less invasive way. Fixes #68477 r? @nikomatsakis cc @eddyb
16 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is ground work for lazy normalization of consts. This enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection.
r? @nikomatsakis