Simplify apply_effects_in_range#159285
Conversation
|
Shouldn't affect perf, let's check: @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.
…r=<try> Simplify `apply_effects_in_range`
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (83bb0c9): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression 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 -2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.4%)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: 491.202s -> 491.32s (0.02%) |
|
Perf is neutral: the regressions are tiny and few and probably noise. |
`ResultsVisitor` has `visit_block_start` which is called on entry to a
a block in a forwards analysis and on exit from a block in a backwards
analysis. And vice versa for `visit_block_end`.
The only visitor that impls these methods is `StateDiffCollector`, which
does something in `visit_block_start` for a forwards analysis and the
same thing in `visit_block_end` for a backwards analysis. In other
words, `StateDiffCollector` wants to always do the same thing on entry
to a block and never do anything on exit from a block.
This commit replaces `visit_block_{start,end}` with `visit_block_entry`,
which is always called on entry to a block. This is simpler overall.
By adding more methods to `Direction`. This makes things more concise, and these new methods will be used more in subsequent commits.
This commit adds `Analysis::apply_effect`, which takes an `EffectIndex` and calls the appropriate `Analysis::apply_*` method. Once that is in place, it is possible to use it with `next_index` to write a simple `apply_effects_in_range` method that can be shared between `Forward` and `Backward`. The end result is much easier to understand.
3b49173 to
cd61331
Compare
|
Some changes occurred in src/tools/cargo cc @ehuss |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
|
I have added two new commits that address the comments. @rustbot ready |
It's only used by `StateDiffCollector`, and it's just a complicated way to get the entry state, which can instead be done directly (avoiding the creation of a `bottom_value` which was immediately overwritten).
It has a single call site. The commit removes the assertions because they necessary any more due to the assertions and checks at the call site. This then removes the need for `index_precedes`.
cd61331 to
e736635
Compare
These were accidental; I have reverted them. |
Details in individual commits.
r? @cjgillot