coverage: Simplify building the coverage graph with CoverageSuccessors
#119508
Conversation
This file contains 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 has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot
added
the
A-code-coverage
Zalathar
changed the title
SuccessorsCoverageSuccessors
Zalathar
force-pushed
the
graph
branch
2 times, most recently
from
e52cac3 to
1eef281
Compare
DanielFrantes
approved these changes
Jan 2, 2024
Zalathar
force-pushed
the
graph
branch
4 times, most recently
from
fa2de49 to
021719a
Compare
|
Hmm, I was writing up some more comments on the (incidental) switch to boxed slices, and it occurred to me that That kind of undermines one of my reasons for using boxed slices, since doing so is less “free” than I had assumed. |
Filtering out unreachable successors is only needed by the main graph traversal loop, so we can move the filtering step into that loop instead, eliminating the need to pass the MIR body into `bcb_filtered_successors`.
The old loop had two separate places where it would flush the acumulated list of straight-line blocks into a new BCB. One occurred at the start of the loop body when the current block couldn't be chained into, and the other occurred at the end of the loop body when the current block couldn't be chained from. The latter check can be hoisted to the start of the loop body by making it examine the previous block (which has added itself to the list) instead of the current block. With that done, we can combine the two separate flushes into one flush with two possible trigger conditions.
This also switches from `split_off(0)` to `std::mem::take` when emptying the accumulated list of blocks, because `split_off(0)` handles capacity in a way that is unintuitive when used in a loop.
|
@bors r+ |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 15, 2024
coverage: Simplify building the coverage graph with `CoverageSuccessors` This is a collection of simplifications to the code that builds the *basic coverage block* graph, which is a simplified view of the MIR control-flow graph that ignores panics and merges straight-line sequences of blocks into a single BCB node. The biggest change is to how we determine the coverage-relevant successors of a block. Previously we would call `Terminator::successors` and apply some ad-hoc postprocessing, but with this PR we instead have our own `match` on the terminator kind that produces a coverage-specific enum `CoverageSuccessors`. That enum also includes information about whether a block has exactly one successor that it can be chained into as part of a single BCB.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 15, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#119508 (coverage: Simplify building the coverage graph with `CoverageSuccessors`) - rust-lang#119818 (Silence some follow-up errors [3/x]) - rust-lang#119870 (std: Doc blocking behavior of LazyLock) - rust-lang#119963 (Fix `allow_internal_unstable` for `(min_)specialization`) - rust-lang#119968 (Remove unused/unnecessary features) - rust-lang#119971 (Use `zip_eq` to enforce that things being zipped have equal sizes) - rust-lang#119974 (Minor `trimmed_def_paths` improvements) r? `@ghost` `@rustbot` modify labels: rollup
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (73252d5): comparison URL. Overall result: ❌ regressions - 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 666.737s -> 669.714s (0.45%) |
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.
This is a collection of simplifications to the code that builds the basic coverage block graph, which is a simplified view of the MIR control-flow graph that ignores panics and merges straight-line sequences of blocks into a single BCB node.
The biggest change is to how we determine the coverage-relevant successors of a block. Previously we would call
Terminator::successorsand apply some ad-hoc postprocessing, but with this PR we instead have our ownmatchon the terminator kind that produces a coverage-specific enumCoverageSuccessors. That enum also includes information about whether a block has exactly one successor that it can be chained into as part of a single BCB.