Dont rerun stalled goals if erased runs succeeded*#157910
Conversation
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Dont rerun stalled goals if erased runs succeeded*
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (d5c2f17): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -3.0%, secondary -38.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -34.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 522.814s -> 518.78s (-0.77%) |
| // Whether erased queries succeeded matters for judging whether opaque | ||
| // storage changes are relevant. If we're eagerly propagating up, the | ||
| // it's because the parent is running in erased mode, and the opaque | ||
| // type storage is empty: i.e. opaque storage changes aren't relevant | ||
| // anyway and Yes is a fine answer to give. | ||
| SucceededInErased::Yes { accessed_opaques }, |
There was a problem hiding this comment.
This should be unreachable, should it not? 🤔 we should never propagate to the parent and then reprove the goal in our EvalCtxt
* Unless the succesful erased run was conditional on the state of opaque type storage, and the opaque type storage changed in a significant way
r? @lcnr