Files
rust/tests/mir-opt
Matthias Krüger 4aae8d15d6 Rollup merge of #135481 - Zalathar:node-flow, r=oli-obk
coverage: Completely overhaul counter assignment, using node-flow graphs

The existing code for choosing where to put physical counter-increments gets the job done, but is very ad-hoc and hard to modify without introducing tricky regressions.

This PR replaces all of that with a more principled approach, based on the algorithm described in "Optimal measurement points for program frequency counts" (Knuth & Stevenson, 1973).

---

We start by ensuring that our graph has “balanced flow”, i.e. each node's flow (execution count) is equal to the sum of all its in-edge flows, and equal to the sum of all its out-edge flows. That isn't naturally true of control-flow graphs, so we introduce a wrapper type `BalancedFlowGraph` to fix that by introducing synthetic nodes and edges as needed.

Once our graph has balanced flow, the next step is to create another view of that graph in which each node's successors have all been merged into one “supernode”. Consequently, each node's out-edges can be coalesced into a single out-edge to one of those supernodes. Because of the balanced-flow property, the flow of that coalesced edge is equal to the flow of the original node.

Having expressed all of our node flows as edge flows, we can then analyze node flows using techniques for analyzing edge flows. We incrementally build a spanning tree over the merged supernodes, such that each new edge in the spanning tree represents a node whose flow can be computed from that of other nodes.

When this is done, we end up with a list of “counter terms” for each node, describing which nodes need physical counters, and how the remaining nodes can have their flow calculated by adding and subtracting those physical counters.

---

The re-blessed coverage tests show that this results in modest or major improvements for our test programs. Some tests need fewer physical counters, some tests need fewer expression nodes for the same number of physical counters, and some tests show striking reductions in both.
2025-01-16 18:46:09 +01:00
..
2025-01-11 15:56:58 -08:00
2024-06-03 14:17:16 +10:00
2024-09-27 14:40:38 +01:00
2024-09-27 14:40:38 +01:00
2024-12-02 16:19:17 +11:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-08-18 15:52:23 -07:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-02-13 17:21:53 +00:00
2024-08-18 15:52:23 -07:00
2024-08-18 15:52:23 -07:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-06-16 18:23:48 +02:00
2025-01-11 15:56:58 -08:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-01-28 13:50:20 -06:00
2024-06-03 14:17:16 +10:00
2024-06-03 14:17:16 +10:00
2024-08-10 12:07:17 +02:00
2024-08-10 12:07:17 +02:00
2024-06-03 14:17:16 +10:00

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.

Testing a particular MIR pass

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

//@ test-mir-pass: 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. This also lets you test passes that are disabled by default.

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

FileCheck directives

The LLVM FileCheck tool is used to verify the contents of output MIR against CHECK directives present in the test file. This works on the runtime MIR, generated by --emit=mir, and not on the output of a individual passes.

Use // skip-filecheck to prevent FileCheck from running.

To check MIR for function foo, start with a // CHECK-LABEL fn foo( directive.

{{regex}} syntax allows to match regex.

[[name:regex]] syntax allows to bind name to a string matching regex, and refer to it as [[name]] in later directives, regex should be written not to match a leading space. Use [[my_local:_.*]] to name a local, and [[my_bb:bb.*]] to name a block.

Documentation for FileCheck is available here: https://www.llvm.org/docs/CommandGuide/FileCheck.html