coverage: Use a separate counter type and simplification step during counter creation #133849
Conversation
A "site" is a node or edge in the coverage graph.
This is more convenient for subsequent patches.
These simplifications are now handled by the transcribe step.
Zalathar
added
the
A-code-coverage
|
rustbot has assigned @petrochenkov. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
This churns all of the coverage tests, so it will conflict with any other PR (e.g. #133089) that re-blesses the |
| } | ||
| } | ||
|
|
||
| fn transcribe_counters(mut self) -> CoverageCounters { |
There was a problem hiding this comment.
So this is basically a normalization if there are no old counters and a system for keeping the diff small if there are old counters?
There was a problem hiding this comment.
This is kind of tricky to explain, but it's also the whole crux of this PR, so I should try.
We can think of this code as going through a series of refactoring stages:
- Graph traversal →
CoverageCounters(status quo) - Graph traversal →
CoverageCounters→Transcriber→ simplifiedCoverageCounters - Graph traversal →
FxHashMap<Site, SiteCounter>→Transcriber→ simplifiedCoverageCounters
The main goal of introducing Transcriber as a middle layer is so that the part before Transcriber can be changed to not be tied to CoverageCounters. To make that feasible, we need to go through the intermediate step of having two different CoverageCounters (old and new), so that we can then replace the first one with something else.
There was a problem hiding this comment.
The fact that final CoverageCounters is simpler than the original one starts off as being a bonus extra, but it also lets the earlier steps not care so much about producing “optimal” results in a single pass. I expect that to be a big help in future changes to how counter creation works.
|
r? @oli-obk |
|
@bors r+ |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#133737 (Include LLDB and GDB visualizers in MSVC distribution) - rust-lang#133774 (Make CoercePointee errors translatable) - rust-lang#133831 (Don't try and handle unfed `type_of` on anon consts) - rust-lang#133847 (Remove `-Zshow-span`.) - rust-lang#133849 (coverage: Use a separate counter type and simplification step during counter creation) - rust-lang#133850 (Avoid `opaque type not constrained` errors in the presence of other errors) - rust-lang#133851 (Stop git from merging generated files) - rust-lang#133856 (Update sysinfo version to 0.33.0) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#133849 - Zalathar:replay, r=oli-obk coverage: Use a separate counter type and simplification step during counter creation When instrumenting a function's MIR for coverage, there is a point where we need to decide, for each node in the control-flow graph, whether its execution count will be tracked by a physical counter, or by an expression that combines physical counters from other parts of the graph. Currently the code for doing that is heavily tied to the final form of the LLVM coverage mapping format, and performs some important simplification steps on-the-fly. These factors make the code extremely difficult to modify without breaking or massively worsening the resulting coverage-instrumentation metadata. --- This PR aims to improve that situation somewhat by adding an extra intermediate representation between the code that chooses how each node will be counted, and the code that converts those decisions into actual tables of physical counters and trees of counter expressions. As part of doing that, some of the simplifications that are currently performed during the main counter creation step have been pulled out into a separate step. In most cases the resulting coverage metadata is equivalent, slightly better, or slightly worse. The biggest outlier is `counters.rs`, where the coverage metadata ends up about 10% larger. This seems to be the result of the new approach having less subexpression sharing (because it relies on flatten-sort-cancel), and therefore being less effective at taking advantage of MIR optimizations to replace counters for unused control-flow with zeroes. I think the modest downside is acceptable in light of the future possibilities opened up by this decoupling.
When instrumenting a function's MIR for coverage, there is a point where we need to decide, for each node in the control-flow graph, whether its execution count will be tracked by a physical counter, or by an expression that combines physical counters from other parts of the graph.
Currently the code for doing that is heavily tied to the final form of the LLVM coverage mapping format, and performs some important simplification steps on-the-fly. These factors make the code extremely difficult to modify without breaking or massively worsening the resulting coverage-instrumentation metadata.
This PR aims to improve that situation somewhat by adding an extra intermediate representation between the code that chooses how each node will be counted, and the code that converts those decisions into actual tables of physical counters and trees of counter expressions.
As part of doing that, some of the simplifications that are currently performed during the main counter creation step have been pulled out into a separate step.
In most cases the resulting coverage metadata is equivalent, slightly better, or slightly worse. The biggest outlier is
counters.rs, where the coverage metadata ends up about 10% larger. This seems to be the result of the new approach having less subexpression sharing (because it relies on flatten-sort-cancel), and therefore being less effective at taking advantage of MIR optimizations to replace counters for unused control-flow with zeroes. I think the modest downside is acceptable in light of the future possibilities opened up by this decoupling.