Multi-version Program Dependency Graphs

• Multi-version PDGs are unified graphs built from disjoint unions of single-version PDGs, preserving version-specific semantics for change analysis.
• They explicitly capture data-flow and control-flow dependencies across revisions, supporting commit untangling and invariant-based semantic differencing.
• Empirical evaluations show significant improvements in commit classification accuracy and systematic edit mining, confirming delta-PDG’s practical impact on software evolution.

Searching arXiv for the cited papers to ground the article in the current record. Multi-version Program Dependency Graphs, commonly denoted $\delta$-PDGs, are change-sensitive program representations that extend the standard Program Dependency Graph (PDG) from a single program version to multiple versions of the same code base. In the formulation used for commit untangling, a PDG is a directed graph in which each node represents a program statement or conditional expression and each edge represents a data-flow or control-flow dependency; the corresponding multi-version PDG $\delta$-$PDG^{i,j}$ is the disjoint union of the PDGs for versions $i$ and $j$, so that pre-change and post-change nodes and edges coexist in one graph while remaining version-distinct (Hou et al., 22 Jul 2025). Closely related work uses near-equivalent multi-version structures even when the term $\delta$-PDG is not explicit: "Invariant Diffs" organizes multi-version control flow in an MVICFG and treats demand-driven symbolic propagation as something very close to data-dependence slices over that graph (Joshy et al., 2019), while "Sirius" builds old/new fine-grained PDGs plus cross-version mappings into change graphs that are effectively two-version PDGs with explicit alignment (Noda et al., 2021).

1. Formal definition and graph semantics

In the standard single-version formulation, the PDG for a version $v$ is written as

$PDG^v = (N^v, E^v)$

where $N^v$ is the set of nodes and $E^v$ is the set of edges. Nodes denote statements or conditional expressions; edges denote data dependencies and control dependencies. The multi-version PDG between versions $\delta$0 and $\delta$1 is then defined as

$\delta$2

with

$\delta$3

where $\delta$4 denotes disjoint union, so nodes and edges from the two versions are kept distinct rather than merged (Hou et al., 22 Jul 2025).

This disjoint-union definition is central. It means that a $\delta$5-PDG is not merely a graph difference in the sense of deleting common structure and keeping only edits. Instead, it is a joint semantic space over the before and after versions. In practice, each node is labeled with its version, location, and statement text or AST. The change dimension is then recovered by classifying nodes as additions, deletions, modifications, or unchanged code. In the illustrations reported for ColaUntangle, red nodes represent statements before the change, green nodes represent modified statements in the after version, and gray nodes represent unchanged statements across versions (Hou et al., 22 Jul 2025).

A common misconception is that a $\delta$6-PDG directly encodes every kind of relationship relevant to software evolution. The current literature is narrower. In the commit-untangling formulation, $\delta$7-PDGs encode explicit dependencies—data-flow and control-flow edges—while implicit dependencies such as semantic or conceptual relatedness are inferred later by downstream reasoning components rather than added as first-class graph edges (Hou et al., 22 Jul 2025).

2. Construction across versions and representation of deltas

The basic construction pipeline starts from two versions of a program, typically the parent and child revisions of a commit. For each version, one builds a PDG and then forms the multi-version graph by disjoint union. The resulting graph contains pre-change statements, post-change statements, and the dependencies internal to each version. The delta is expressed through version-tagged node membership and node-level change classification, rather than through a separate edit script alone (Hou et al., 22 Jul 2025).

For commit-oriented analysis, the key subset is the set $\delta$8 of changed nodes. Two derived subgraphs are then extracted. The explicit context graph keeps only changed nodes and the dependency relations among them. If two changed nodes are directly connected, their original edge is retained. If they are not directly connected but there exists a dependency path through unchanged nodes, a compressed edge is added between them and labeled with the variables involved in the data flow along the original path. Formally, the retained node set is $\delta$9, and the compressed graph records both direct and path-compressed dependency relations among those changed nodes (Hou et al., 22 Jul 2025).

The implicit context graph is a neighborhood-expanded view. It retains all changed nodes and their one-hop neighbors: $PDG^{i,j}$0 and includes all edges among the retained nodes. This graph is intentionally less compressed than the explicit context graph and preserves more surrounding code information (Hou et al., 22 Jul 2025).

A second construction style appears in "Sirius," which operates with fine-grained PDGs at expression level. For a method or code fragment $PDG^{i,j}$1, its fine-grained PDG is denoted $PDG^{i,j}$2 and can be represented as

$PDG^{i,j}$3

where nodes correspond to expression-level program elements and labels abstract over types, literals, and method invocations. A code change is then represented as a change graph

$PDG^{i,j}$4

where $PDG^{i,j}$5 is a node mapping induced from AST differencing. This is explicitly described as a two-version PDG with alignment, even though the paper does not name it a $PDG^{i,j}$6-PDG (Noda et al., 2021).

3. Alignment, matched regions, and adjacent multi-version representations

Current work uses several closely related representations for cross-version semantic analysis. They differ mainly in whether control flow, dependence, and cross-version alignment are explicit in one graph or distributed across analysis state.

Work	Core structure	Role
ColaUntangle	$PDG^{i,j}$7-$PDG^{i,j}$8	Explicit dependency reasoning over changed statements
Invariant Diffs	MVICFG with version-tagged nodes and edges	Multi-version symbolic propagation and invariant comparison
Sirius	$PDG^{i,j}$9	Change-graph mining and replay of systematic edits

In "Invariant Diffs," the primary representation is a multiversion interprocedural CFG rather than a PDG. Nodes represent IR statements or basic blocks, structurally identical nodes can be shared across versions, and edges are annotated with the set of versions in which they exist. A matched program point is a shared node reachable in all versions of interest and free of textual diffs. The paper states that the MVICFG already implements the control-flow aspect of a multi-version PDG: it shares nodes across versions, tracks per-edge version membership, and provides matched nodes as alignment anchors (Joshy et al., 2019).

That observation is significant because it clarifies what a full multi-version PDG would add. To obtain a $i$0-PDG from the MVICFG, one would compute data-dependence edges and control-dependence edges, annotate them with version sets, and reuse the same shared nodes and version tags. The demand-driven symbolic propagation used for invariant inference is described as computing something very close to data-dependence slices over the MVICFG; in a $i$1-PDG, those slices would become explicit graph structure (Joshy et al., 2019).

This suggests a general alignment principle across the literature: multi-version program graphs need stable anchors at which cross-version comparison is meaningful. In ColaUntangle, those anchors are changed statements and their dependency neighborhoods; in H$i$2, they are matched program points; in Sirius, they are old/new node mappings $i$3 derived from AST alignment (Hou et al., 22 Jul 2025).

4. Analysis over $i$4-PDGs: dependencies, invariants, and graph transformations

In commit untangling, the $i$5-PDG is used as the substrate for two distinct reasoning modes. The explicit worker agent reads the explicit context graph and reasons that code changes connected by data dependencies or control dependencies often belong to the same concern. The implicit worker agent reads the implicit context graph, which retains changed nodes plus one-hop neighbors, and uses that broader neighborhood to reason about semantic similarity, textual and structural similarity, and cosmetic edits. The reviewer agent then synthesizes both perspectives through iterative consultation (Hou et al., 22 Jul 2025).

A second analytical use is semantic differencing through invariants. "Invariant Diffs" defines a version invariant as a condition held true for all selected versions at a matched program point, and an invariant churn as a tuple

$i$6

that records which invariants were added or removed between versions and which added, deleted, or shared source lines contributed to the change. Although this framework is implemented over MVICFGs rather than PDGs, the paper explicitly notes that a multi-version PDG could attach invariants to aligned nodes and use backward, path-sensitive propagation as a multi-version slice from the node of interest (Joshy et al., 2019).

"Sirius" uses yet another $i$7-PDG-like analysis mode: systematic edit mining and replay. Fine-grained old and new PDGs, together with their mapping $i$8, form change graphs from which frequent subgraph mining extracts systematic edit patterns. An SEP is effectively a pair of old/new PDG fragments plus a cross-version mapping. The detector searches for subgraphs in client code isomorphic to the old side of the pattern, and the transformer realizes the PDG-level change at the AST level through Minimum Transplantable induced Subtrees. In this sense, the mined pattern functions as a graph transformation rule with a left-hand side, a right-hand side, and an alignment between them (Noda et al., 2021).

Across these uses, $i$9-PDGs support three distinct but compatible interpretations: as explicit dependency evidence for clustering changes, as alignment anchors for semantic invariants, and as graph-level change templates for transformation.

5. Empirical uses and reported results

The strongest direct empirical evidence for $j$0-PDGs as a practical representation comes from commit untangling. ColaUntangle evaluates on two datasets comprising 1,612 C# tangled commits and 14k Java tangled commits. On the combined C# and Java ablation, removing $j$1-PDG-derived explicit and implicit contexts ("w/o Info Tools") lowers performance from $j$2 and $j$3 to $j$4 and $j$5, a reported 9.46% drop in $j$6 and 2% drop in $j$7. Against prior $j$8-PDG-based baselines on the C# dataset, ColaUntangle reports $j$9 and $\delta$0, compared with $\delta$1 for $\delta$2-PDG + CV, $\delta$3 for Flexeme, and $\delta$4 for UTango. On Java, the reported $\delta$5 rises from 38% for HD-GNN to 76% for ColaUntangle, described as a 100% improvement (Hou et al., 22 Jul 2025).

The invariant-based line of work shows how multi-version graph structure can support semantic differencing rather than clustering. H$\delta$6 was evaluated on 104 versions of programs drawn from a benchmark of student solutions to 10 small mathematical tasks. Every task had non-trivial version invariants across 6 versions, version invariants often decreased as more diverse implementations were included, and invariant churns captured the semantic essence of 21 out of 23 buggy/fixed version pairs. The reported average IChurn/line is 1.37, and time is under 1 second in all 23 buggy/fixed pairs, with average time approximately 111 ms (Joshy et al., 2019).

The repair-oriented line demonstrates that PDG-based multi-version differencing can support transformation rather than description alone. Sirius built 288,497 change graphs from 88 Java projects, mined 6,060 fgPDG-based SEPs with minimum support 3, and evaluated 31,273 repair trials. The reported results are precision 0.710, recall 0.565, and F1-score 0.630, compared with 0.470, 0.141, and 0.216 for ARES-2. About 90% of SEPs have size at most 10 nodes, and Sirius maintains high precision, approximately 0.8, and recall, approximately 0.6, for pattern-size thresholds $\delta$7 (Noda et al., 2021).

Taken together, these findings indicate that multi-version dependence-based representations have already been used for at least three research tasks: untangling commits, explaining semantic behavioral changes, and mining reusable edit transformations.

6. Limitations, misconceptions, and open directions

The main limitations reported in the literature arise from graph construction, static analysis fidelity, and scale. ColaUntangle notes a threat to validity from reliance on static analysis tools, whose accuracy and reliability can be limited when handling complex language features; it also reports average inference time of approximately 125 seconds per commit, cost of about \$2.92 per 100 examples, and average consultation rounds of 1.27–1.38, indicating that LLM inference rather than graph construction is the dominant cost in that framework (Hou et al., 22 Jul 2025).

The invariant-differencing framework has representation-specific constraints. H$\delta$8 is intra-procedural in the current prototype, loops are handled by single unrolling, and the implemented analysis focuses on templates such as equalities and simple inequalities over LLVM IR. The paper states that a multi-version PDG generalization would therefore need interprocedural structure, richer invariant domains, and more sophisticated handling of loops, aliasing, and heap modeling (Joshy et al., 2019).

Sirius exposes a different set of limitations: expensive subgraph isomorphism during detection, heuristic path-based PDG mapping, and transformation imprecision when PDG-level changes must be realized at AST level. In a sampled failure analysis, incorrect mined SEPs accounted for 40% of failures, excessive transplantation for 24%, insufficient deletion for 17%, incorrect detection for 8%, and imprecision in AST differencing for 8% (Noda et al., 2021).

Several misconceptions are directly addressed by the current evidence. First, a $\delta$9-PDG is not just a text diff with graph notation; its purpose is to preserve data-flow and control-flow semantics across versions. Second, a $v$0-PDG does not, by itself, encode implicit semantic relations; in ColaUntangle those relations are inferred by LLMs from graph-derived context rather than represented as new edges. Third, multi-version semantic analysis does not require that every framework explicitly materialize a PDG. The MVICFG in "Invariant Diffs" is presented as one analysis step away from a multi-version PDG, while the change graphs in "Sirius" are already interpretable as two-version PDGs with explicit cross-version alignment (Hou et al., 22 Jul 2025).

A plausible implication is that future multi-version PDG research will converge on richer hybrid forms: explicit dependence structure for precise cross-version semantics, stable alignment anchors such as matched nodes or mapped nodes, and graph-derived annotations for value-level properties such as invariants or systematic edit rules. The present literature already supplies the core ingredients for that synthesis, even though they are distributed across different task-specific formulations.