2023-07-22 08:23:39 +00:00
|
|
|
use crate::coverageinfo::ffi::{Counter, CounterExpression, ExprKind};
|
2020-07-29 06:09:16 +00:00
|
|
|
|
2023-08-14 08:01:28 +00:00
|
|
|
use rustc_data_structures::fx::FxIndexSet;
|
2023-07-23 01:48:31 +00:00
|
|
|
use rustc_index::IndexVec;
|
|
|
|
use rustc_middle::mir::coverage::{CodeRegion, CounterId, ExpressionId, Op, Operand};
|
2020-07-25 04:14:28 +00:00
|
|
|
use rustc_middle::ty::Instance;
|
|
|
|
use rustc_middle::ty::TyCtxt;
|
2020-07-02 18:27:15 +00:00
|
|
|
|
2021-03-13 00:00:00 +00:00
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
2020-10-05 23:36:10 +00:00
|
|
|
pub struct Expression {
|
2023-06-26 12:28:48 +00:00
|
|
|
lhs: Operand,
|
2020-08-15 11:42:13 +00:00
|
|
|
op: Op,
|
2023-06-26 12:28:48 +00:00
|
|
|
rhs: Operand,
|
2020-10-05 23:36:10 +00:00
|
|
|
region: Option<CodeRegion>,
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Collects all of the coverage regions associated with (a) injected counters, (b) counter
|
|
|
|
/// expressions (additions or subtraction), and (c) unreachable regions (always counted as zero),
|
2023-06-29 02:14:04 +00:00
|
|
|
/// for a given Function. This struct also stores the `function_source_hash`,
|
2020-07-25 04:14:28 +00:00
|
|
|
/// computed during instrumentation, and forwarded with counters.
|
2020-06-22 06:29:08 +00:00
|
|
|
///
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Note, it may be important to understand LLVM's definitions of `unreachable` regions versus "gap
|
|
|
|
/// regions" (or "gap areas"). A gap region is a code region within a counted region (either counter
|
|
|
|
/// or expression), but the line or lines in the gap region are not executable (such as lines with
|
|
|
|
/// only whitespace or comments). According to LLVM Code Coverage Mapping documentation, "A count
|
|
|
|
/// for a gap area is only used as the line execution count if there are no other regions on a
|
|
|
|
/// line."
|
2021-05-01 21:56:48 +00:00
|
|
|
#[derive(Debug)]
|
2020-10-05 23:36:10 +00:00
|
|
|
pub struct FunctionCoverage<'tcx> {
|
|
|
|
instance: Instance<'tcx>,
|
2020-07-02 18:27:15 +00:00
|
|
|
source_hash: u64,
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
is_used: bool,
|
2023-06-29 02:36:19 +00:00
|
|
|
counters: IndexVec<CounterId, Option<CodeRegion>>,
|
2023-06-29 02:14:04 +00:00
|
|
|
expressions: IndexVec<ExpressionId, Option<Expression>>,
|
2020-08-15 11:42:13 +00:00
|
|
|
unreachable_regions: Vec<CodeRegion>,
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2020-10-05 23:36:10 +00:00
|
|
|
impl<'tcx> FunctionCoverage<'tcx> {
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
/// Creates a new set of coverage data for a used (called) function.
|
2020-10-05 23:36:10 +00:00
|
|
|
pub fn new(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> Self {
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
Self::create(tcx, instance, true)
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Creates a new set of coverage data for an unused (never called) function.
|
|
|
|
pub fn unused(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> Self {
|
|
|
|
Self::create(tcx, instance, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn create(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>, is_used: bool) -> Self {
|
2021-05-12 03:56:23 +00:00
|
|
|
let coverageinfo = tcx.coverageinfo(instance.def);
|
2020-10-05 23:36:10 +00:00
|
|
|
debug!(
|
2021-05-12 03:56:23 +00:00
|
|
|
"FunctionCoverage::create(instance={:?}) has coverageinfo={:?}. is_used={}",
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
instance, coverageinfo, is_used
|
2020-10-05 23:36:10 +00:00
|
|
|
);
|
2020-07-02 18:27:15 +00:00
|
|
|
Self {
|
2020-10-05 23:36:10 +00:00
|
|
|
instance,
|
2020-07-02 18:27:15 +00:00
|
|
|
source_hash: 0, // will be set with the first `add_counter()`
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
is_used,
|
2020-07-29 00:45:58 +00:00
|
|
|
counters: IndexVec::from_elem_n(None, coverageinfo.num_counters as usize),
|
|
|
|
expressions: IndexVec::from_elem_n(None, coverageinfo.num_expressions as usize),
|
2020-07-25 04:14:28 +00:00
|
|
|
unreachable_regions: Vec::new(),
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
/// Returns true for a used (called) function, and false for an unused function.
|
|
|
|
pub fn is_used(&self) -> bool {
|
|
|
|
self.is_used
|
|
|
|
}
|
|
|
|
|
2020-10-25 18:13:16 +00:00
|
|
|
/// Sets the function source hash value. If called multiple times for the same function, all
|
|
|
|
/// calls should have the same hash value.
|
2020-10-05 23:36:10 +00:00
|
|
|
pub fn set_function_source_hash(&mut self, source_hash: u64) {
|
|
|
|
if self.source_hash == 0 {
|
|
|
|
self.source_hash = source_hash;
|
|
|
|
} else {
|
|
|
|
debug_assert_eq!(source_hash, self.source_hash);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Adds a code region to be counted by an injected counter intrinsic.
|
2023-06-29 02:36:19 +00:00
|
|
|
pub fn add_counter(&mut self, id: CounterId, region: CodeRegion) {
|
2021-03-13 00:00:00 +00:00
|
|
|
if let Some(previous_region) = self.counters[id].replace(region.clone()) {
|
|
|
|
assert_eq!(previous_region, region, "add_counter: code region for id changed");
|
|
|
|
}
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Both counters and "counter expressions" (or simply, "expressions") can be operands in other
|
2023-06-29 02:14:04 +00:00
|
|
|
/// expressions. These are tracked as separate variants of `Operand`, so there is no ambiguity
|
|
|
|
/// between operands that are counter IDs and operands that are expression IDs.
|
2020-07-02 18:27:15 +00:00
|
|
|
pub fn add_counter_expression(
|
|
|
|
&mut self,
|
2023-06-29 02:14:04 +00:00
|
|
|
expression_id: ExpressionId,
|
2023-06-26 12:28:48 +00:00
|
|
|
lhs: Operand,
|
2020-08-15 11:42:13 +00:00
|
|
|
op: Op,
|
2023-06-26 12:28:48 +00:00
|
|
|
rhs: Operand,
|
2020-10-05 23:36:10 +00:00
|
|
|
region: Option<CodeRegion>,
|
2020-06-22 06:29:08 +00:00
|
|
|
) {
|
2020-10-05 23:36:10 +00:00
|
|
|
debug!(
|
|
|
|
"add_counter_expression({:?}, lhs={:?}, op={:?}, rhs={:?} at {:?}",
|
|
|
|
expression_id, lhs, op, rhs, region
|
|
|
|
);
|
2021-05-01 21:56:48 +00:00
|
|
|
debug_assert!(
|
2023-06-29 02:14:04 +00:00
|
|
|
expression_id.as_usize() < self.expressions.len(),
|
|
|
|
"expression_id {} is out of range for expressions.len() = {}
|
2021-05-01 21:56:48 +00:00
|
|
|
for {:?}",
|
2023-06-29 02:14:04 +00:00
|
|
|
expression_id.as_usize(),
|
2021-05-01 21:56:48 +00:00
|
|
|
self.expressions.len(),
|
|
|
|
self,
|
|
|
|
);
|
2023-06-29 02:14:04 +00:00
|
|
|
if let Some(previous_expression) = self.expressions[expression_id].replace(Expression {
|
2021-03-13 00:00:00 +00:00
|
|
|
lhs,
|
|
|
|
op,
|
|
|
|
rhs,
|
|
|
|
region: region.clone(),
|
|
|
|
}) {
|
|
|
|
assert_eq!(
|
|
|
|
previous_expression,
|
|
|
|
Expression { lhs, op, rhs, region },
|
|
|
|
"add_counter_expression: expression for id changed"
|
|
|
|
);
|
|
|
|
}
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Add a region that will be marked as "unreachable", with a constant "zero counter".
|
2020-08-15 11:42:13 +00:00
|
|
|
pub fn add_unreachable_region(&mut self, region: CodeRegion) {
|
2020-08-02 03:03:59 +00:00
|
|
|
self.unreachable_regions.push(region)
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
|
|
|
|
2023-08-14 08:01:28 +00:00
|
|
|
/// Perform some simplifications to make the final coverage mappings
|
|
|
|
/// slightly smaller.
|
|
|
|
///
|
|
|
|
/// This method mainly exists to preserve the simplifications that were
|
|
|
|
/// already being performed by the Rust-side expression renumbering, so that
|
|
|
|
/// the resulting coverage mappings don't get worse.
|
|
|
|
pub(crate) fn simplify_expressions(&mut self) {
|
|
|
|
// The set of expressions that either were optimized out entirely, or
|
|
|
|
// have zero as both of their operands, and will therefore always have
|
|
|
|
// a value of zero. Other expressions that refer to these as operands
|
|
|
|
// can have those operands replaced with `Operand::Zero`.
|
|
|
|
let mut zero_expressions = FxIndexSet::default();
|
|
|
|
|
|
|
|
// For each expression, perform simplifications based on lower-numbered
|
|
|
|
// expressions, and then update the set of always-zero expressions if
|
|
|
|
// necessary.
|
|
|
|
// (By construction, expressions can only refer to other expressions
|
|
|
|
// that have lower IDs, so one simplification pass is sufficient.)
|
|
|
|
for (id, maybe_expression) in self.expressions.iter_enumerated_mut() {
|
|
|
|
let Some(expression) = maybe_expression else {
|
|
|
|
// If an expression is missing, it must have been optimized away,
|
|
|
|
// so any operand that refers to it can be replaced with zero.
|
|
|
|
zero_expressions.insert(id);
|
|
|
|
continue;
|
|
|
|
};
|
|
|
|
|
|
|
|
// If an operand refers to an expression that is always zero, then
|
|
|
|
// that operand can be replaced with `Operand::Zero`.
|
|
|
|
let maybe_set_operand_to_zero = |operand: &mut Operand| match &*operand {
|
|
|
|
Operand::Expression(id) if zero_expressions.contains(id) => {
|
|
|
|
*operand = Operand::Zero;
|
|
|
|
}
|
|
|
|
_ => (),
|
|
|
|
};
|
|
|
|
maybe_set_operand_to_zero(&mut expression.lhs);
|
|
|
|
maybe_set_operand_to_zero(&mut expression.rhs);
|
|
|
|
|
|
|
|
// Coverage counter values cannot be negative, so if an expression
|
|
|
|
// involves subtraction from zero, assume that its RHS must also be zero.
|
|
|
|
// (Do this after simplifications that could set the LHS to zero.)
|
|
|
|
if let Expression { lhs: Operand::Zero, op: Op::Subtract, .. } = expression {
|
|
|
|
expression.rhs = Operand::Zero;
|
|
|
|
}
|
|
|
|
|
|
|
|
// After the above simplifications, if both operands are zero, then
|
|
|
|
// we know that this expression is always zero too.
|
|
|
|
if let Expression { lhs: Operand::Zero, rhs: Operand::Zero, .. } = expression {
|
|
|
|
zero_expressions.insert(id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Return the source hash, generated from the HIR node structure, and used to indicate whether
|
|
|
|
/// or not the source code structure changed between different compilations.
|
2020-07-02 18:27:15 +00:00
|
|
|
pub fn source_hash(&self) -> u64 {
|
|
|
|
self.source_hash
|
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Generate an array of CounterExpressions, and an iterator over all `Counter`s and their
|
|
|
|
/// associated `Regions` (from which the LLVM-specific `CoverageMapGenerator` will create
|
|
|
|
/// `CounterMappingRegion`s.
|
2021-12-14 02:52:35 +00:00
|
|
|
pub fn get_expressions_and_counter_regions(
|
|
|
|
&self,
|
|
|
|
) -> (Vec<CounterExpression>, impl Iterator<Item = (Counter, &CodeRegion)>) {
|
2020-10-05 23:36:10 +00:00
|
|
|
assert!(
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
self.source_hash != 0 || !self.is_used,
|
|
|
|
"No counters provided the source_hash for used function: {:?}",
|
2020-10-05 23:36:10 +00:00
|
|
|
self.instance
|
|
|
|
);
|
2020-07-25 04:14:28 +00:00
|
|
|
|
2023-07-23 01:48:31 +00:00
|
|
|
let counter_expressions = self.counter_expressions();
|
|
|
|
// Expression IDs are indices into `self.expressions`, and on the LLVM
|
|
|
|
// side they will be treated as indices into `counter_expressions`, so
|
|
|
|
// the two vectors should correspond 1:1.
|
|
|
|
assert_eq!(self.expressions.len(), counter_expressions.len());
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
let counter_regions = self.counter_regions();
|
2023-07-23 01:48:31 +00:00
|
|
|
let expression_regions = self.expression_regions();
|
2020-07-25 04:14:28 +00:00
|
|
|
let unreachable_regions = self.unreachable_regions();
|
|
|
|
|
|
|
|
let counter_regions =
|
|
|
|
counter_regions.chain(expression_regions.into_iter().chain(unreachable_regions));
|
2020-07-29 00:45:58 +00:00
|
|
|
(counter_expressions, counter_regions)
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2021-12-14 02:52:35 +00:00
|
|
|
fn counter_regions(&self) -> impl Iterator<Item = (Counter, &CodeRegion)> {
|
2020-07-29 00:45:58 +00:00
|
|
|
self.counters.iter_enumerated().filter_map(|(index, entry)| {
|
2020-07-25 04:14:28 +00:00
|
|
|
// Option::map() will return None to filter out missing counters. This may happen
|
|
|
|
// if, for example, a MIR-instrumented counter is removed during an optimization.
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
entry.as_ref().map(|region| (Counter::counter_value_reference(index), region))
|
2020-07-25 04:14:28 +00:00
|
|
|
})
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2023-07-23 01:48:31 +00:00
|
|
|
/// Convert this function's coverage expression data into a form that can be
|
|
|
|
/// passed through FFI to LLVM.
|
|
|
|
fn counter_expressions(&self) -> Vec<CounterExpression> {
|
|
|
|
// We know that LLVM will optimize out any unused expressions before
|
|
|
|
// producing the final coverage map, so there's no need to do the same
|
|
|
|
// thing on the Rust side unless we're confident we can do much better.
|
|
|
|
// (See `CounterExpressionsMinimizer` in `CoverageMappingWriter.cpp`.)
|
2020-07-25 04:14:28 +00:00
|
|
|
|
2023-07-23 01:48:31 +00:00
|
|
|
self.expressions
|
|
|
|
.iter()
|
|
|
|
.map(|expression| match expression {
|
|
|
|
None => {
|
|
|
|
// This expression ID was allocated, but we never saw the
|
|
|
|
// actual expression, so it must have been optimized out.
|
|
|
|
// Replace it with a dummy expression, and let LLVM take
|
|
|
|
// care of omitting it from the expression list.
|
|
|
|
CounterExpression::DUMMY
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
}
|
2023-07-23 01:48:31 +00:00
|
|
|
&Some(Expression { lhs, op, rhs, .. }) => {
|
|
|
|
// Convert the operands and operator as normal.
|
|
|
|
CounterExpression::new(
|
|
|
|
Counter::from_operand(lhs),
|
|
|
|
match op {
|
|
|
|
Op::Add => ExprKind::Add,
|
|
|
|
Op::Subtract => ExprKind::Subtract,
|
|
|
|
},
|
|
|
|
Counter::from_operand(rhs),
|
|
|
|
)
|
2020-10-05 23:36:10 +00:00
|
|
|
}
|
2023-07-23 01:48:31 +00:00
|
|
|
})
|
|
|
|
.collect::<Vec<_>>()
|
|
|
|
}
|
|
|
|
|
|
|
|
fn expression_regions(&self) -> Vec<(Counter, &CodeRegion)> {
|
|
|
|
// Find all of the expression IDs that weren't optimized out AND have
|
|
|
|
// an attached code region, and return the corresponding mapping as a
|
|
|
|
// counter/region pair.
|
|
|
|
self.expressions
|
|
|
|
.iter_enumerated()
|
|
|
|
.filter_map(|(id, expression)| {
|
|
|
|
let code_region = expression.as_ref()?.region.as_ref()?;
|
|
|
|
Some((Counter::expression(id), code_region))
|
|
|
|
})
|
|
|
|
.collect::<Vec<_>>()
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
2020-07-02 18:27:15 +00:00
|
|
|
|
2021-12-14 02:52:35 +00:00
|
|
|
fn unreachable_regions(&self) -> impl Iterator<Item = (Counter, &CodeRegion)> {
|
2023-08-02 05:55:37 +00:00
|
|
|
self.unreachable_regions.iter().map(|region| (Counter::ZERO, region))
|
2020-07-25 04:14:28 +00:00
|
|
|
}
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|