-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Allow to feed a value in another query's cache and remove WithOptConstParam
#96840
Conversation
This comment has been minimized.
This comment has been minimized.
impl<$tcx> TyCtxtFeed<$tcx> { | ||
$($(#[$attr])* | ||
#[inline(always)] | ||
pub fn $name<V>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to only allow this for queries which explicitly opt-in? And then maybe not allow setting any provider for such queries. I think that makes the information flow a lot clearer.
☔ The latest upstream changes (presumably #96473) made this pull request unmergeable. Please resolve the merge conflicts. |
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in const_evaluatable.rs cc @lcnr Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks rustbot. So much for the discretion of a WIP PR 😄
r? compiler |
☔ The latest upstream changes (presumably #100759) made this pull request unmergeable. Please resolve the merge conflicts. |
looked through this PR and I am really happy about not seeing The query system is complex enough for me to not be comfortable approving this. My thoughts:
going to hand off this review to incr comp people, but I am looking forward to this PR landing. I do think it requires an MCP though. r? @wesleywiser maybe, @michaelwoerister isn't available much rn afaict |
This is not really possible yet. I could remove the case where
Mmh... I wonder where to put this message. Do you have an example of such misuse?
Done.
We do not ICE, we check that both values' fingerprints match. |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
@bors r=oli-obk |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
rust/compiler/rustc_middle/src/ty/consts.rs Line 129 in 1f5768b
One reference to |
Finished benchmarking commit (1f5768b): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Add regression tests for const-generic inherent associated types Fixes rust-lang#109759. The tests are no longer failing since rust-lang#96840 which was merged recently (rust-lang#109410 is no longer necessary for them). `@rustbot` label F-inherent_associated_types
Allow to feed a value in another query's cache and remove `WithOptConstParam` I used it to remove `WithOptConstParam` queries, as an example. The idea is that a query (here `typeck(function)`) can write into another query's cache (here `type_of(anon const)`). The dependency node for `type_of` would depend on all the current dependencies of `typeck`. There is still an issue with cycles: if `type_of(anon const)` is accessed before `typeck(function)`, we will still have the usual cycle. The way around this issue is to `ensure` that `typeck(function)` is called before accessing `type_of(anon const)`. When replayed, we may the following cases: - `typeck` is green, in that case `type_of` is green too, and all is right; - `type_of` is green, `typeck` may still be marked as red (it depends on strictly more things than `type_of`) -> we verify that the saved value and the re-computed value of `type_of` have the same hash; - `type_of` is red, then `typeck` is red -> it's the caller responsibility to ensure `typeck` is recomputed *before* `type_of`. As `anon consts` have their own `DefPathData`, it's not possible to have the def-id of the anon-const point to something outside the original function, but the general case may have to be resolved before using this device more broadly. There is an open question about loading from the on-disk cache. If `typeck` is loaded from the on-disk cache, the side-effect does not happen. The regular `type_of` implementation can go and fetch the correct value from the decoded `typeck` results, and the dep-graph will check that the hashes match, but I'm not sure we want to rely on this behaviour. I specifically allowed to feed the value to `type_of` from inside a call to `type_of`. In that case, the dep-graph will check that the fingerprints of both values match. This implementation is still very sensitive to cycles, and requires that we call `typeck(function)` before `typeck(anon const)`. The reason is that `typeck(anon const)` calls `type_of(anon const)`, which calls `typeck(function)`, which feeds `type_of(anon const)`, and needs to build the MIR so needs `typeck(anon const)`. The latter call would not cycle, since `type_of(anon const)` has been set, but I'd rather not remove the cycle check.
I used it to remove
WithOptConstParam
queries, as an example.The idea is that a query (here
typeck(function)
) can write into another query's cache (heretype_of(anon const)
). The dependency node fortype_of
would depend on all the current dependencies oftypeck
.There is still an issue with cycles: if
type_of(anon const)
is accessed beforetypeck(function)
, we will still have the usual cycle. The way around this issue is toensure
thattypeck(function)
is called before accessingtype_of(anon const)
.When replayed, we may the following cases:
typeck
is green, in that casetype_of
is green too, and all is right;type_of
is green,typeck
may still be marked as red (it depends on strictly more things thantype_of
) -> we verify that the saved value and the re-computed value oftype_of
have the same hash;type_of
is red, thentypeck
is red -> it's the caller responsibility to ensuretypeck
is recomputed beforetype_of
.As
anon consts
have their ownDefPathData
, it's not possible to have the def-id of the anon-const point to something outside the original function, but the general case may have to be resolved before using this device more broadly.There is an open question about loading from the on-disk cache. If
typeck
is loaded from the on-disk cache, the side-effect does not happen. The regulartype_of
implementation can go and fetch the correct value from the decodedtypeck
results, and the dep-graph will check that the hashes match, but I'm not sure we want to rely on this behaviour.I specifically allowed to feed the value to
type_of
from inside a call totype_of
. In that case, the dep-graph will check that the fingerprints of both values match.This implementation is still very sensitive to cycles, and requires that we call
typeck(function)
beforetypeck(anon const)
. The reason is thattypeck(anon const)
callstype_of(anon const)
, which callstypeck(function)
, which feedstype_of(anon const)
, and needs to build the MIR so needstypeck(anon const)
. The latter call would not cycle, sincetype_of(anon const)
has been set, but I'd rather not remove the cycle check.