probably.pgcl.cfg Internals

class probably.pgcl.cfg._Region(dominator_id, instrs, successor_id)[source]

A region is like a basic block, but it contains general program statements instead of only assignments and has

Parameters:
dominator_id: Optional[NewType(BasicBlockId, int)]
instrs: List[Union[SkipInstr, WhileInstr, IfInstr, AsgnInstr, ChoiceInstr, LoopInstr, TickInstr, ObserveInstr, ProbabilityQueryInstr, ExpectationInstr, PlotInstr, PrintInstr, OptimizationQuery]]
successor_id: Optional[NewType(BasicBlockId, int)]
static initial(initial_block_id)[source]
Parameters:

initial_block_id (Optional[NewType(BasicBlockId, int)]) –

Return type:

_Region

static child(parent_id, block_id)[source]
Parameters:
Return type:

_Region

dominates_successor(frontiers)[source]
Parameters:

frontiers (Dict[NewType(BasicBlockId, int), List[NewType(BasicBlockId, int)]]) –

Return type:

bool

add_block(block, instrs, successor_id)[source]
Parameters:
probably.pgcl.cfg._expand_region(graph, frontiers, region)[source]

See reduce_cfg_to_instrs(). Given a control-flow graph for a program, the dominance frontiers and a block id, create a block (i.e. list of instructions) where each statement in the block dominates the next statements. All statements in that block eventually end up in the second returned item, the successor’s block id.

Parameters:
probably.pgcl.cfg._join_regions(graph, region1, region2)[source]

For if instructions, both branches must continue with the same block. Let’s call this block the join point. For programs generated using ControlFlowGraph.from_instructions(), this will be the case. However, programs modified by one_big_loop() do not necessarily have proper join points. An example can be seen in the documentation of one_big_loop(). We handle those cases here explicitly by duplicating trampoline blocks.

Parameters:
Return type:

bool