-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
coverage: Simplify building coverage expressions based on sums #117651
Conversation
e138d9a
to
959517f
Compare
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
/// no benefit in having a separate counter for its in-edge, because it | ||
/// would have the same value as the node's own counter. | ||
/// | ||
/// FIXME: That assumption might not be true for [`TerminatorKind::Yield`]? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this concern is equally true of the old code and the new code.
It's just a corner-case that came to mind while writing up these docs.
2017d54
to
b38fb70
Compare
f0decb2
to
c41a60c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me with one nit
/// FIXME: That assumption might not be true for [`TerminatorKind::Yield`]? | ||
#[inline(always)] | ||
pub(super) fn bcb_has_multiple_in_edges(&self, bcb: BasicCoverageBlock) -> bool { | ||
self.predecessors[bcb].len() > 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be a special case for the entry bcb?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added an extra patch with some assertions/comments explaining why we don't have to worry about the special case of bcb0.
4f3ac74
to
a5e574a
Compare
@rustbot ready |
☔ The latest upstream changes (presumably #118143) made this pull request unmergeable. Please resolve the merge conflicts. |
4d2be8e
to
c1bbb0d
Compare
(I've been rebasing because I have other work that builds on top of this branch, but I haven't been making further changes.) |
This lets us avoid creating two copies of the node's branch list.
Now that this code path unconditionally calls `make_branch_counters`, we might as well make that method responsible for creating the node's counter as well, since it needs the resulting term anyway.
This means that we no longer have to manage the distinction between `BcbCounter` and `CovTerm` when preparing expressions.
In some cases we need to prepare a coverage expression that is the sum of an arbitrary number of other terms. This patch simplifies the code paths that build those sums. This causes some churn in the mappings, because the previous code was building its sums in a somewhat idiosyncratic order.
This was previously a helper method in `MakeBcbCounters`, but putting it in the graph lets us call it from `BcbBranch`, and gives us a more fine-grained borrow.
`BcbBranch` represented an out-edge of a coverage graph node, but would silently refer to a node instead in cases where that node only had one in-edge. Instead we now refer to a graph edge as a `(from_bcb, to_bcb)` pair, or sometimes as just one of those nodes when the other node is implied by the surrounding context. The case of sole in-edges is handled by special code added directly to `get_or_make_edge_counter_operand`.
This explains why we don't have to worry about bcb0 having multiple in-edges.
@bors r+ |
…mpiler-errors Rollup of 7 pull requests Successful merges: - rust-lang#117651 (coverage: Simplify building coverage expressions based on sums) - rust-lang#117968 (Stabilize `ptr::addr_eq`) - rust-lang#118158 (Reduce fluent boilerplate) - rust-lang#118201 (Miscellaneous `ObligationCauseCode` cleanups) - rust-lang#118288 (Use `is_{some,ok}_and` more in the compiler) - rust-lang#118289 (`is_{some,ok}_and` for rustdoc) - rust-lang#118290 (Don't ICE when encountering placeholders in implied bounds computation) r? `@ghost` `@rustbot` modify labels: rollup
…mpiler-errors Rollup of 7 pull requests Successful merges: - rust-lang#117651 (coverage: Simplify building coverage expressions based on sums) - rust-lang#117968 (Stabilize `ptr::addr_eq`) - rust-lang#118158 (Reduce fluent boilerplate) - rust-lang#118201 (Miscellaneous `ObligationCauseCode` cleanups) - rust-lang#118288 (Use `is_{some,ok}_and` more in the compiler) - rust-lang#118289 (`is_{some,ok}_and` for rustdoc) - rust-lang#118290 (Don't ICE when encountering placeholders in implied bounds computation) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#117651 - Zalathar:fold-sums, r=cjgillot coverage: Simplify building coverage expressions based on sums This is a combination of some interlinked changes to the code that creates coverage counters/expressions for nodes and edges in the coverage graph: - Some preparatory cleanups in `MakeBcbCounters::make_branch_counters` - Use `BcbCounter` (instead of `CovTerm`) when building coverage expressions - This makes it easier to introduce a fold for building sums - Simplify the creation of coverage expressions based on sums, by having `Iterator::fold` do much of the work - Get rid of the awkward `BcbBranch` enum, and replace it with graph edges represented as `(from_bcb, to_bcb)` - This further simplifies the body of the fold
This is a combination of some interlinked changes to the code that creates coverage counters/expressions for nodes and edges in the coverage graph:
MakeBcbCounters::make_branch_counters
BcbCounter
(instead ofCovTerm
) when building coverage expressionsIterator::fold
do much of the workBcbBranch
enum, and replace it with graph edges represented as(from_bcb, to_bcb)