Documentation

A control flow graph where edges have been annotated with a weight. Implemented as IntMap (IntMap <edgeData>) We must uphold the invariant that for each edge A -> B we must have: A entry B in the outer map. A entry B in the map we get when looking up A. Maintaining this invariant is useful as any failed lookup now indicates an actual error in code which might go unnoticed for a while otherwise.

Information about edges

Can we trace back a edge to a specific Cmm Node or has it been introduced during assembly codegen. We use this to maintain some information which would otherwise be lost during the Cmm <-> asm transition. See also Note [Inverting conditions]

Adds a edge with the given weight to the cfg If there already existed an edge it is overwritten. `addWeightEdge from to weight cfg`

Adds a new edge, overwrites existing edges if present

Insert a block in the control flow between two other blocks. We pass a list of tuples (A,B,C) where * A -> C: Old edge * A -> B -> C : New Arc, where B is the new block. It's possible that a block has two jumps to the same block in the assembly code. However we still only store a single edge for these cases. We assign the old edge info to the edge A -> B and assign B -> C the weight of an unconditional jump.

Filter the CFG with a custom function f. Parameters are `f from to edgeInfo`

Sometimes we insert a block which should unconditionally be executed after a given block. This function updates the CFG for these cases. So we get A -> B => A -> A' -> B -> C => -> C

Convenience function, generate edge info based on weight not originating from cmm.

Adjust the weight between the blocks using the given function. If there is no such edge returns the original map.

Set the weight between the blocks to the given weight. If there is no such edge returns the original map.

Returns a unordered list of all edges with info

Returns a unordered list of all edges without weights

Get successors of a given node with edge weights.

Get successors of a given node without edge weights.

Destinations from bid ordered by weight (descending)

Is this block part of this graph?

Determine loop membership of blocks based on SCC analysis This is faster but only gives yes/no answers.

Determine loop membership of blocks based on Dominator analysis. This is slower but gives loop levels instead of just loop membership. However it only detects natural loops. Irreducible control flow is not recognized even if it loops. But that is rare enough that we don't have to care about that special case.

Generate weights for a Cmm proc based on some simple heuristics.

Check if the nodes in the cfg and the set of blocks are the same. In a case of a missmatch we panic and show the difference.

We take in a CFG which has on its edges weights which are relative only to other edges originating from the same node.

We return a CFG for which each edge represents a GLOBAL weight. This means edge weights are comparable across the whole graph.

For irreducible control flow results might be imprecise, otherwise they are reliable.

The algorithm is based on the Paper "Static Branch Prediction and Program Profile Analysis" by Y Wu, JR Larus The only big change is that we go over the nodes in the body of loops in reverse post order. Which is required for diamond control flow to work probably.

We also apply a few prediction heuristics (based on the same paper)

The returned result represents frequences. For blocks it's the expected number of executions and for edges is the number of traversals.