36aab8df0a
coverage: Allow each coverage statement to have multiple code regions The original implementation of coverage instrumentation was built around the assumption that a coverage counter/expression would be associated with *up to one* code region. When it was discovered that *multiple* regions would sometimes need to share a counter, a workaround was found: for the remaining regions, the instrumentor would create a fresh expression that adds zero to the existing counter/expression. That got the job done, but resulted in some awkward code, and produces unnecessarily complicated coverage maps in the final binary. --- This PR removes that tension by changing `StatementKind::Coverage`'s code region field from `Option<CodeRegion>` to `Vec<CodeRegion>`. The changes on the codegen side are fairly straightforward. As long as each `CoverageKind::Counter` only injects one `llvm.instrprof.increment`, the rest of coverage codegen is happy to handle multiple regions mapped to the same counter/expression, with only minor option-to-vec adjustments. On the instrumentor/mir-transform side, we can get rid of the code that creates extra (x + 0) expressions. Instead we gather all of the code regions associated with a single BCB, and inject them all into one coverage statement. --- There are several patches here but they can be divided in to three phases: - Preparatory work - Actually switching over to multiple regions per coverage statement - Cleaning up So viewing the patches individually may be easier.
This folder contains tests for MIR optimizations.
The mir-opt test format emits MIR to extra files that you can automatically update by specifying
--bless on the command line (just like ui tests updating .stderr files).
--blessable test format
By default 32 bit and 64 bit targets use the same dump files, which can be problematic in the presence of pointers in constants or other bit width dependent things. In that case you can add
// EMIT_MIR_FOR_EACH_BIT_WIDTH
to your test, causing separate files to be generated for 32bit and 64bit systems.
Unit testing
If you are only testing the behavior of a particular mir-opt pass on some specific input (as is usually the case), you should add
// unit-test: PassName
to the top of the file. This makes sure that other passes don't run which means you'll get the input you expected and your test won't break when other code changes.
Emit a diff of the mir for a specific optimization
This is what you want most often when you want to see how an optimization changes the MIR.
// EMIT_MIR $file_name_of_some_mir_dump.diff
Emit mir after a specific optimization
Use this if you are just interested in the final state after an optimization.
// EMIT_MIR $file_name_of_some_mir_dump.after.mir
Emit mir before a specific optimization
This exists mainly for completeness and is rarely useful.
// EMIT_MIR $file_name_of_some_mir_dump.before.mir