Translating Between PEGs and CFGs

We transform a CFG into a PEG in two steps. First, we transform the CFG into an Abstract PEG (A-PEG). Conceptually, an A-PEG is a PEG that operates over programs stores rather than individual variables, and whose nodes represent the basic blocks of the CFG. Figure 1(b) shows a sample A-PEG, derived from the CFG in Figure 1(a). The A-PEG captures the structure of the original CFG using θ, pass and eval nodes, but does not capture the flow of individual variables, nor the details of how each basic block operates. For each basic block n in the CFG, there is a node SEn in the corresponding A-PEG that represents the execution of the basic block (SE stands for Symbolic Evaluator): given a store at the input of the basic block, SEn returns the store at the output. For basic blocks that have multiple CFG successors, meaning that the last instruction in the block is a branch, we assume that the store returned by SE contains a specially named boolean variable whose value indicates which way the branch will go. The function cond takes a program store, and selects this specially named variable from it. As a result, for a basic block n that ends in a branch, cond(SEn) is a boolean stating which way the branch should go. Once we have an A-PEG, the translation from A-PEG to PEG is simple – all that is left to do is expand the A-PEG to the level of individual variables by replacing each SE n node with a dataflow representation of the instructions in block n. For example, in Figure 1, if there were two variables being assigned in all the basic blocks, then the PEG would essentially contain two structural copies of the A-PEG, one copy for each variable. Our algorithm for converting a CFG into an A-PEG starts with a reducible CFG (all CFGs produced from valid Java code are reducible, and furthermore, if a CFG is not reducible, it can be transformed