Make building THIR a stealable query #85273
Conversation
rust-highfive
added
the
S-waiting-on-review
LeSeulArtichaut
changed the title
|
Note: I still need to fix a bug where unsafeck doesn't report all the errors in a few tests; I'll try to work on that tomorrow |
This comment has been minimized.
This comment has been minimized.
LeSeulArtichaut
force-pushed
the
thir-query
branch
from
a0b9260
to
0ffcfc0
Compare
This comment has been minimized.
This comment has been minimized.
LeSeulArtichaut
force-pushed
the
thir-query
branch
from
1962864
to
a9224c6
Compare
Store THIR in `IndexVec`s instead of an `Arena` This is a necessary step to store the THIR in a query: rust-lang#85273. See [relevant discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/278509-project-thir-unsafeck/topic/THIR-dependent.20queries.20design). r? `@ghost` cc `@cjgillot` `@nikomatsakis`
This comment has been minimized.
This comment has been minimized.
LeSeulArtichaut
force-pushed
the
thir-query
branch
from
a9224c6
to
abaf435
Compare
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit abaf435e2379a1e66ab6e58b1daa87042dba28bc with merge 0c06be8f20e88c1e095d9315104aabcf4535af17... |
|
☀️ Try build successful - checks-actions |
|
Queued 0c06be8f20e88c1e095d9315104aabcf4535af17 with parent f94942d, future comparison URL. |
|
Finished benchmarking try commit (0c06be8f20e88c1e095d9315104aabcf4535af17): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
rustbot
removed
the
S-waiting-on-perf
|
So this costs a few percent as is |
This comment has been minimized.
This comment has been minimized.
|
Ok, so nevermind, building the THIR when a type error occured might not be the best idea. I think I should check for that in |
|
@nikomatsakis I addressed your review comments |
| @@ -14,6 +14,7 @@ macro_rules! arena_types { | |||
| [] layouts: rustc_target::abi::Layout, | |||
| // AdtDef are interned and compared by address | |||
| [] adt_def: rustc_middle::ty::AdtDef, | |||
| [] steal_thir: rustc_data_structures::steal::Steal<rustc_middle::thir::Thir<$tcx>>, | |||
There was a problem hiding this comment.
I wonder if it would be worth making this a Box<Thir>, so that we don't store as many pointers inline in the map.
|
@bors r+ rollup=never |
|
📌 Commit af3d9a3 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
@nikomatsakis @LeSeulArtichaut It would be really nice to have a little bit more examining why the performance hit was deemed acceptable - maybe 1-2 sentences. I assume this was simply "the feature is desired and the impact is small enough for us to not worry about". Does that jive with your thinking? |
|
@rylev basically -- however, I wonder if we should have a bit more of a procedure around cases like this. I see that @LeSeulArtichaut opened #85729 which seems to address the problem. I've not caught up on Zulip yet but I imagine somebody may have suggested that, and if we had discussed it more broadly that might've been caught. I guess to start I can ping rust-lang/compiler in the future. However, I'd like it if we had a bit more documentation to help us decide when it's "worth it" (although I guess it will always be a judgement call to some degree). |
|
I'm thinking something similar to the MCP process-- explain your reasons and give notice when landing a known perf regression and a bit of time for people to respond, but don't require active affirmation. |
|
I opened up a zulip topic with a proposed perf regression policy along these lines: |
|
@rylev It looks like the perf regression is due to hashing the whole THIR tree, which seems ineffective even in incr-patched scenarios. I've proposed to not hash the query in #85729, which seems to negate the regression. If it was not to land for some reason: this is desirable because it allows THIR to be used in different analysis passes but built only once. For now we only use it for MIR building but we will use it for unsafety checking as well (rust-lang/compiler-team#402). We may also be able to shave off some performance by making exhaustiveness checking use the query as well, instead of building its own patterns, though it's not been experimented with yet. |
|
Awesome! Thank you all for this! ♥ |
…atsakis Don't hash `thir_body` Experiment to see if/how much this helps negate the perf impact of rust-lang#85273. r? `@ghost`
…s, r=nikomatsakis Make closures inherit their parent's "safety context" Fixes rust-lang/project-thir-unsafeck#9, ~~blocked on rust-lang#85273~~. r? `@nikomatsakis`
This PR creates a stealable
thir_bodyquery so that we can build the THIR only once for THIR unsafeck and MIR build.Blocked on #83842.
r? @nikomatsakis