Remove fewer Storage calls in GVN #142819
Open
+1,885
−887
Conversation
This file contains hidden or 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
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
@bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
rust-bors bot
added a commit
that referenced
this pull request
Jun 21, 2025
Remove fewer Storage calls in GVN Followup to #142531 (Remove fewer Storage calls in `copy_prop`) Modify the GVN MIR optimization pass to remove fewer Storage{Live,Dead} calls, allowing for better optimizations by LLVM - see #141649. After replacing locals with values, use the `MaybeStorageDead` analysis to check that the replaced locals are storage-live. **A slight problem**: In #142531, `@tmiasko` noted #142531 (comment) that `MaybeStorageDead` isn't enough since there can be a `Live(_1); Dead(_1); Live(_1);` block which forces the optimization to check that each value is initialised (and not only storage-live). This is easy enough in `copy_prop` (because we are checking _before_ the replacement), but in GVN it is actually hard to tell for each statement if the local must be initialized or not after the fact (and modifying `VnState` seems even harder). I opted for something else which might be wrong (implemented in the last two commits): If we consider `Dead->Live` to be the same as `Deinit`, than such a local shouldn't be considered SSA - so I updated `SsaVisitor` to mark such cases as non-SSA. r? tmiasko
This comment has been minimized.
This comment has been minimized.
ohadravid
force-pushed
the
better-storage-calls-gvn-v2
branch
from
1ea73cf to
954274b
Compare
… to remove fewer storage statements
This comment has been minimized.
This comment has been minimized.
ohadravid
force-pushed
the
better-storage-calls-gvn-v2
branch
from
954274b to
780d162
Compare
This comment has been minimized.
This comment has been minimized.
I'm not sure this change is desirable. For now, we only consider assignments in SSA. If we have this sequence: StorageLive(_a);
_a = something;
StorageDead(_a);
StorageLive(_a);
_b = _a;The Instead, I recommend you check for each local which get new use sites:
That should be enough to answer to @tmiasko's counterexample. |
Sounds good, I'll try to implement that - do you think that implementing this using something like the current |
|
Finished benchmarking commit (e92550a): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient 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 0.1%, secondary -3.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 0.4%, secondary 1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.3%, secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 689.042s -> 692.911s (0.56%) |
rustbot
added
perf-regression
That's what I'd do. |
@cjgillot - do we need to check this? Seems like checking for alive locals is enough, since there must always be such a statement? (otherwise it's UB anyway?) I far as I can see there can only be these (non-normal) cases:
handled by
(handled by (in the meantime, pushed a version that's rebased on top of the copy_prop branch which uses |
ohadravid
force-pushed
the
better-storage-calls-gvn-v2
branch
2 times, most recently
from
b00b762 to
a259605
Compare
ohadravid
force-pushed
the
better-storage-calls-gvn-v2
branch
from
a259605 to
f403fb6
Compare
|
For case 1, this is handled by checking if the StorageLive dominates the assignment. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
It seems simpler than modifying Let me know what do you think is preferable 😄 |
|
I mean this MaybeStorageDead: https://doc.rust-lang.org/beta/nightly-rustc/rustc_mir_dataflow/impls/struct.MaybeStorageDead.html |
This is what I used in the original impl, but requires the StorageLive-dominates-assignment check (if I understood correctly). And I think that Again - I might be totally missing something 😅 |
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.
Followup to #142531 (Remove fewer Storage calls in
copy_prop)Modify the GVN MIR optimization pass to remove fewer Storage{Live,Dead} calls, allowing for better optimizations by LLVM - see #141649.
After replacing locals with values, use the
MaybeStorageDeadanalysis to check that the replaced locals are storage-live.A slight problem: In #142531, @tmiasko noted #142531 (comment) that
MaybeStorageDeadisn't enough since there can be aLive(_1); Dead(_1); Live(_1);block which forces the optimization to check that each value is initialised (and not only storage-live).This is easy enough in
copy_prop(because we are checking before the replacement), but in GVN it is actually hard to tell for each statement if the local must be initialized or not after the fact (and modifyingVnStateseems even harder).I opted for something else which might be wrong (implemented in the last two commits):
If we consider
Dead->Liveto be the same asDeinit, than such a local shouldn't be considered SSA - so I updatedSsaVisitorto mark such cases as non-SSA.r? tmiasko