mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
151256bd4b
rust/tests/coverage-map/status-quo/loops_branches.cov-map

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

184 lines
12 KiB
Plaintext
Raw Normal View History

Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Function name: <loops_branches::DebugTest as core::fmt::Debug>::fmt
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
Raw bytes (249): 0x[01, 01, 31, 05, 09, 00, 02, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, bf, 01, c3, 01, 0d, 00, 11, 15, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, b6, 01, 15, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, b2, 01, 1d, b6, 01, 15, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, 00, ae, 01, b2, 01, 1d, b6, 01, 15, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, ab, 01, 11, 00, ae, 01, b2, 01, 1d, b6, 01, 15, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, 25, a3, 01, a6, 01, 19, ab, 01, 11, 00, ae, 01, b2, 01, 1d, b6, 01, 15, bb, 01, 19, bf, 01, c3, 01, 0d, 00, 11, 15, 14, 01, 09, 05, 01, 10, 05, 02, 10, 00, 15, 00, 01, 17, 00, 1b, 00, 00, 1c, 00, 1e, 02, 01, 0e, 00, 0f, 07, 01, 0d, 00, 1e, 25, 00, 1e, 00, 1f, 00, 01, 10, 01, 0a, b6, 01, 03, 0d, 00, 0e, bb, 01, 00, 12, 00, 17, b6, 01, 01, 10, 00, 14, b2, 01, 01, 14, 00, 19, 00, 01, 1b, 00, 1f, 00, 00, 20, 00, 22, ae, 01, 01, 12, 00, 13, ab, 01, 01, 11, 00, 22, a6, 01, 00, 22, 00, 23, 00, 01, 14, 01, 0e, 19, 03, 09, 00, 0f, 9f, 01, 01, 05, 00, 06]
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Number of files: 1
- file 0 => global file 1
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
Number of expressions: 49
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- expression 0 operands: lhs = Counter(1), rhs = Counter(2)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- expression 1 operands: lhs = Zero, rhs = Expression(0, Sub)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- expression 2 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 3 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- expression 4 operands: lhs = Counter(3), rhs = Zero
- expression 5 operands: lhs = Counter(4), rhs = Counter(5)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- expression 6 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- expression 7 operands: lhs = Counter(3), rhs = Zero
- expression 8 operands: lhs = Counter(4), rhs = Counter(5)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- expression 9 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 10 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
- expression 11 operands: lhs = Counter(3), rhs = Zero
- expression 12 operands: lhs = Counter(4), rhs = Counter(5)
- expression 13 operands: lhs = Expression(45, Sub), rhs = Counter(5)
- expression 14 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 15 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
- expression 16 operands: lhs = Counter(3), rhs = Zero
- expression 17 operands: lhs = Counter(4), rhs = Counter(5)
- expression 18 operands: lhs = Expression(44, Sub), rhs = Counter(7)
- expression 19 operands: lhs = Expression(45, Sub), rhs = Counter(5)
- expression 20 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 21 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
- expression 22 operands: lhs = Counter(3), rhs = Zero
- expression 23 operands: lhs = Counter(4), rhs = Counter(5)
- expression 24 operands: lhs = Zero, rhs = Expression(43, Sub)
- expression 25 operands: lhs = Expression(44, Sub), rhs = Counter(7)
- expression 26 operands: lhs = Expression(45, Sub), rhs = Counter(5)
- expression 27 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 28 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
- expression 29 operands: lhs = Counter(3), rhs = Zero
- expression 30 operands: lhs = Counter(4), rhs = Counter(5)
- expression 31 operands: lhs = Expression(42, Add), rhs = Counter(4)
- expression 32 operands: lhs = Zero, rhs = Expression(43, Sub)
- expression 33 operands: lhs = Expression(44, Sub), rhs = Counter(7)
- expression 34 operands: lhs = Expression(45, Sub), rhs = Counter(5)
- expression 35 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 36 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
- expression 37 operands: lhs = Counter(3), rhs = Zero
- expression 38 operands: lhs = Counter(4), rhs = Counter(5)
- expression 39 operands: lhs = Counter(9), rhs = Expression(40, Add)
- expression 40 operands: lhs = Expression(41, Sub), rhs = Counter(6)
- expression 41 operands: lhs = Expression(42, Add), rhs = Counter(4)
- expression 42 operands: lhs = Zero, rhs = Expression(43, Sub)
- expression 43 operands: lhs = Expression(44, Sub), rhs = Counter(7)
- expression 44 operands: lhs = Expression(45, Sub), rhs = Counter(5)
- expression 45 operands: lhs = Expression(46, Add), rhs = Counter(6)
- expression 46 operands: lhs = Expression(47, Add), rhs = Expression(48, Add)
- expression 47 operands: lhs = Counter(3), rhs = Zero
- expression 48 operands: lhs = Counter(4), rhs = Counter(5)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Number of file 0 mappings: 20
- Code(Counter(0)) at (prev + 9, 5) to (start + 1, 16)
- Code(Counter(1)) at (prev + 2, 16) to (start + 0, 21)
- Code(Zero) at (prev + 1, 23) to (start + 0, 27)
- Code(Zero) at (prev + 0, 28) to (start + 0, 30)
- Code(Expression(0, Sub)) at (prev + 1, 14) to (start + 0, 15)
= (c1 - c2)
- Code(Expression(1, Add)) at (prev + 1, 13) to (start + 0, 30)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= (Zero + (c1 - c2))
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- Code(Counter(9)) at (prev + 0, 30) to (start + 0, 31)
- Code(Zero) at (prev + 1, 16) to (start + 1, 10)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(45, Sub)) at (prev + 3, 13) to (start + 0, 14)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= (((c3 + Zero) + (c4 + c5)) - c6)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(46, Add)) at (prev + 0, 18) to (start + 0, 23)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= ((c3 + Zero) + (c4 + c5))
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(45, Sub)) at (prev + 1, 16) to (start + 0, 20)
= (((c3 + Zero) + (c4 + c5)) - c6)
- Code(Expression(44, Sub)) at (prev + 1, 20) to (start + 0, 25)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= ((((c3 + Zero) + (c4 + c5)) - c6) - c5)
- Code(Zero) at (prev + 1, 27) to (start + 0, 31)
- Code(Zero) at (prev + 0, 32) to (start + 0, 34)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(43, Sub)) at (prev + 1, 18) to (start + 0, 19)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= (((((c3 + Zero) + (c4 + c5)) - c6) - c5) - c7)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(42, Add)) at (prev + 1, 17) to (start + 0, 34)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= (Zero + (((((c3 + Zero) + (c4 + c5)) - c6) - c5) - c7))
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(41, Sub)) at (prev + 0, 34) to (start + 0, 35)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= ((Zero + (((((c3 + Zero) + (c4 + c5)) - c6) - c5) - c7)) - c4)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- Code(Zero) at (prev + 1, 20) to (start + 1, 14)
- Code(Counter(6)) at (prev + 3, 9) to (start + 0, 15)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(39, Add)) at (prev + 1, 5) to (start + 0, 6)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= (c9 + (((Zero + (((((c3 + Zero) + (c4 + c5)) - c6) - c5) - c7)) - c4) + c6))
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Function name: <loops_branches::DisplayTest as core::fmt::Display>::fmt
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
Raw bytes (253): 0x[01, 01, 33, 01, 05, 02, 09, 00, 0e, 02, 09, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, c3, 01, c7, 01, 05, 0d, 11, 15, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, ba, 01, 11, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, b6, 01, 1d, ba, 01, 11, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, 00, b2, 01, b6, 01, 1d, ba, 01, 11, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, af, 01, 15, 00, b2, 01, b6, 01, 1d, ba, 01, 11, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, aa, 01, cb, 01, af, 01, 15, 00, b2, 01, b6, 01, 1d, ba, 01, 11, bf, 01, 19, c3, 01, c7, 01, 05, 0d, 11, 15, 19, 25, 14, 01, 22, 05, 01, 11, 00, 01, 12, 01, 0a, 02, 02, 10, 00, 15, 00, 01, 17, 00, 1b, 00, 00, 1c, 00, 1e, 0e, 01, 0e, 00, 0f, 0b, 01, 0d, 00, 1e, 25, 00, 1e, 00, 1f, ba, 01, 02, 0d, 00, 0e, bf, 01, 00, 12, 00, 17, ba, 01, 01, 10, 00, 15, 00, 00, 16, 01, 0e, b6, 01, 02, 14, 00, 19, 00, 01, 1b, 00, 1f, 00, 00, 20, 00, 22, b2, 01, 01, 12, 00, 13, af, 01, 01, 11, 00, 22, aa, 01, 00, 22, 00, 23, 19, 03, 09, 00, 0f, a7, 01, 01, 05, 00, 06]
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Number of files: 1
- file 0 => global file 1
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
Number of expressions: 51
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- expression 0 operands: lhs = Counter(0), rhs = Counter(1)
- expression 1 operands: lhs = Expression(0, Sub), rhs = Counter(2)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- expression 2 operands: lhs = Zero, rhs = Expression(3, Sub)
- expression 3 operands: lhs = Expression(0, Sub), rhs = Counter(2)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- expression 4 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 5 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- expression 6 operands: lhs = Counter(1), rhs = Counter(3)
- expression 7 operands: lhs = Counter(4), rhs = Counter(5)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- expression 8 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- expression 9 operands: lhs = Counter(1), rhs = Counter(3)
- expression 10 operands: lhs = Counter(4), rhs = Counter(5)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- expression 11 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 12 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
- expression 13 operands: lhs = Counter(1), rhs = Counter(3)
- expression 14 operands: lhs = Counter(4), rhs = Counter(5)
- expression 15 operands: lhs = Expression(46, Sub), rhs = Counter(4)
- expression 16 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 17 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
- expression 18 operands: lhs = Counter(1), rhs = Counter(3)
- expression 19 operands: lhs = Counter(4), rhs = Counter(5)
- expression 20 operands: lhs = Expression(45, Sub), rhs = Counter(7)
- expression 21 operands: lhs = Expression(46, Sub), rhs = Counter(4)
- expression 22 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 23 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
- expression 24 operands: lhs = Counter(1), rhs = Counter(3)
- expression 25 operands: lhs = Counter(4), rhs = Counter(5)
- expression 26 operands: lhs = Zero, rhs = Expression(44, Sub)
- expression 27 operands: lhs = Expression(45, Sub), rhs = Counter(7)
- expression 28 operands: lhs = Expression(46, Sub), rhs = Counter(4)
- expression 29 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 30 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
- expression 31 operands: lhs = Counter(1), rhs = Counter(3)
- expression 32 operands: lhs = Counter(4), rhs = Counter(5)
- expression 33 operands: lhs = Expression(43, Add), rhs = Counter(5)
- expression 34 operands: lhs = Zero, rhs = Expression(44, Sub)
- expression 35 operands: lhs = Expression(45, Sub), rhs = Counter(7)
- expression 36 operands: lhs = Expression(46, Sub), rhs = Counter(4)
- expression 37 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 38 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
- expression 39 operands: lhs = Counter(1), rhs = Counter(3)
- expression 40 operands: lhs = Counter(4), rhs = Counter(5)
- expression 41 operands: lhs = Expression(42, Sub), rhs = Expression(50, Add)
- expression 42 operands: lhs = Expression(43, Add), rhs = Counter(5)
- expression 43 operands: lhs = Zero, rhs = Expression(44, Sub)
- expression 44 operands: lhs = Expression(45, Sub), rhs = Counter(7)
- expression 45 operands: lhs = Expression(46, Sub), rhs = Counter(4)
- expression 46 operands: lhs = Expression(47, Add), rhs = Counter(6)
- expression 47 operands: lhs = Expression(48, Add), rhs = Expression(49, Add)
- expression 48 operands: lhs = Counter(1), rhs = Counter(3)
- expression 49 operands: lhs = Counter(4), rhs = Counter(5)
- expression 50 operands: lhs = Counter(6), rhs = Counter(9)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Number of file 0 mappings: 20
- Code(Counter(0)) at (prev + 34, 5) to (start + 1, 17)
- Code(Zero) at (prev + 1, 18) to (start + 1, 10)
- Code(Expression(0, Sub)) at (prev + 2, 16) to (start + 0, 21)
= (c0 - c1)
- Code(Zero) at (prev + 1, 23) to (start + 0, 27)
- Code(Zero) at (prev + 0, 28) to (start + 0, 30)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
- Code(Expression(3, Sub)) at (prev + 1, 14) to (start + 0, 15)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= ((c0 - c1) - c2)
- Code(Expression(2, Add)) at (prev + 1, 13) to (start + 0, 30)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= (Zero + ((c0 - c1) - c2))
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- Code(Counter(9)) at (prev + 0, 30) to (start + 0, 31)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(46, Sub)) at (prev + 2, 13) to (start + 0, 14)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= (((c1 + c3) + (c4 + c5)) - c6)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(47, Add)) at (prev + 0, 18) to (start + 0, 23)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= ((c1 + c3) + (c4 + c5))
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(46, Sub)) at (prev + 1, 16) to (start + 0, 21)
= (((c1 + c3) + (c4 + c5)) - c6)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- Code(Zero) at (prev + 0, 22) to (start + 1, 14)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(45, Sub)) at (prev + 2, 20) to (start + 0, 25)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= ((((c1 + c3) + (c4 + c5)) - c6) - c4)
- Code(Zero) at (prev + 1, 27) to (start + 0, 31)
- Code(Zero) at (prev + 0, 32) to (start + 0, 34)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(44, Sub)) at (prev + 1, 18) to (start + 0, 19)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
= (((((c1 + c3) + (c4 + c5)) - c6) - c4) - c7)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(43, Add)) at (prev + 1, 17) to (start + 0, 34)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= (Zero + (((((c1 + c3) + (c4 + c5)) - c6) - c4) - c7))
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(42, Sub)) at (prev + 0, 34) to (start + 0, 35)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= ((Zero + (((((c1 + c3) + (c4 + c5)) - c6) - c4) - c7)) - c5)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
- Code(Counter(6)) at (prev + 3, 9) to (start + 0, 15)
coverage: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-18 23:15:33 -05:00
- Code(Expression(41, Add)) at (prev + 1, 5) to (start + 0, 6)
coverage: Explicitly simplify coverage expressions in codegen After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-08-14 03:01:28 -05:00
= (((Zero + (((((c1 + c3) + (c4 + c5)) - c6) - c4) - c7)) - c5) + (c6 + c9))
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 06:29:41 -05:00
Function name: loops_branches::main
Raw bytes (9): 0x[01, 01, 00, 01, 01, 37, 01, 05, 02]
Number of files: 1
- file 0 => global file 1
Number of expressions: 0
Number of file 0 mappings: 1
- Code(Counter(0)) at (prev + 55, 1) to (start + 5, 2)
Reference in New Issue Copy Permalink