1

IncIDFA: An Efficient and Generic Algorithm for Incremental

Iterative Dataflow Analysis
AMAN NOUGRAHIYA, Department of CSE, IIT Madras, India
V. KRISHNA NANDIVADA, Department of CSE, IIT Madras, India
Iterative dataflow analyses (IDFAs) are important static analyses employed by tools like compilers for en-
abling program optimizations, comprehension, verification, and more. During compilation of a program,
optimizations/transformations can render existing dataflow solutions stale, jeopardizing the optimality and
correctness of subsequent compiler passes. Exhaustively recomputing these solutions can be costly. Since
most program changes impact only small portions of the flowgraph, several incrementalization approaches
have been proposed for various subclasses of IDFAs. However, these approaches face one or more of these
limitations: (i) loss of precision compared to exhaustive analysis, (ii) inability to handle arbitrary lattices and
dataflow functions, and (iii) lacking fully automated incrementalization of the IDFA. As a result, mainstream
compilers lack frameworks for generating precise incremental versions of arbitrary IDFAs, leaving analysis
writers to create ad hoc algorithms for incrementalization – an often cumbersome and error-prone task.
To tackle these challenges, we introduce IncIDFA, a novel algorithm that delivers precise and efficient
incremental variants of any monotone IDFA. IncIDFA utilizes a two-pass approach to maintain precision.
Unlike prior works, IncIDFA avoids resetting the dataflow solutions to least informative values when dealing
with strongly-connected regions and arbitrary program changes. We formally prove the precision guarantees
of IncIDFA for arbitrary dataflow problems and program changes. IncIDFA has been implemented in the
IMOP compiler framework for parallel OpenMP C programs. To showcase its generality, we have instantiated
IncIDFA to ten specific dataflow analyses, without requiring any additional code for incrementalization. We
present an evaluation of IncIDFA on a real-world set of optimization passes, across two different architectures.
As compared to exhaustive recomputation, IncIDFA resulted in a speedup of up to 11× (geomean 2.6×) in
incremental-update time, and improvement of up to 46% (geomean 15.1%) in the total compilation time.
ACM Reference Format:
Aman Nougrahiya and V. Krishna Nandivada. 2025. IncIDFA: An Efficient and Generic Algorithm for Incre-
mental Iterative Dataflow Analysis. Proc. ACM Program. Lang. 2, 1, Article 1 (January 2025), 51 pages.

1 INTRODUCTION
Iterative dataflow analyses cover substantial number of static analyses that compute meaningful
information (for example, reaching definitions, live variables, points-to information, and so on) by
propagating the information across any flow graph of the program (such as control-flow graphs
and call-graphs) until a fixed-point is reached. A general lattice-theoretic framework for IDFA was
first given by Kildall [70], followed by a plethora of other improvements [26, 28, 37, 49, 50, 53, 59,
62, 63, 66–69, 89, 95, 96, 104, 129, 145]. Given the generality and ease of use of the IDFA framework,
it is fairly common for compiler writers to implement custom instantiations of IDFA with arbitrary
lattices to meet their specific requirements.
These analyses results are used by many optimizations invoked during compilation, which in
turn lead to many programs changes. These changes may render existing dataflow solutions stale,
jeopardizing the optimality, or even correctness, of the downstream compiler passes. Exhaustively
recomputing the dataflow solutions in response to such program changes by rerunning the analyses
from scratch can be cost prohibitive. Similar challenges arise throughout a program’s lifecycle,

Authors’ addresses: Aman Nougrahiya, [email protected], Department of CSE, IIT Madras, India; V. Krishna
Nandivada, [email protected], Department of CSE, IIT Madras, India.

2025. 2475-1421/2025/1-ART1 $15.00

https://doi.org/

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:2 Nougrahiya and Nandivada

such as during development and debugging in an IDE or CI pipelines, or even during execution by
managed runtimes (such as during hot-code replacement in JIT compilers).
Since most program changes typically affect only a small region of the program or a small part
of the dataflow solution, prior research has proposed different incremental analysis algorithms
for specific IDFA problems [17, 24, 25, 45, 48, 72, 75, 76, 79, 82, 100, 121, 126, 143, 148, 149, 151]. An
incremental analysis takes the old dataflow solution, the set of program changes performed, and
the updated program, to obtain the new dataflow solution without rerunning the dataflow analysis
on the updated program from scratch. Clearly, designing custom incremental algorithms for each
new dataflow problem can be tedious and error-prone.
To address these challenges, for nearly four decades, researchers have explored generic incremen-
talization approaches for different subclasses of IDFA [7, 27, 32, 42, 65, 67, 83, 90, 97, 137, 138, 150].
Unfortunately, despite extensive research, current incrementalization approaches1 suffer from one
or more of the following limitations:
• From-scratch precision. While incremental approaches like those by Cooper and Kennedy [27],
Ghoddsi [42], Nichols et al. [90], Van der Plas et al. [137, 138] offer faster convergence to a fixed-
point, they do not guarantee the precision achieved by complete invalidation and exhaustive
recomputation of the dataflow solution from scratch. This loss of precision can hinder the optimality
of various client optimization passes. A critical analysis of the precision guarantees of contemporary
incrementalization algorithms has been provided by Burke and Ryder [16].
• Arbitrary lattices and dataflow functions. Many prior works are limited by the types of lattices
or dataflow functions they can handle. Examples include works of Keables et al. [65] and Zadeck
[150] (a subset of set-union problems); Ghoddsi [42] and Khedker [67] (bit-vector analyses/gen-
kill/separable analyses); Pollock and Soffa [97], Marlowe and Ryder [83], Arzt and Bodden [7],
and Do et al. [32] (distributive dataflow problems, such as IFDS/IDE [89, 104]). Further, many
restrictively assume that changes in the amount of information at a basic block (such as updated
GEN and KILL sets [87]) can be determined by inspecting only that block, without requiring the
dataflow results from the other blocks. This limits their applicability to various widely-used and
important dataflow problems, such as points-to analysis, constant-propagation analysis, and so on.
• Automated incrementalization of new dataflow problems. Most existing approaches that preserve
precision, such as those by Marlowe and Ryder [83], Pollock and Soffa [97], Zadeck [150], rely on
detailed case analysis of the type of program changes performed, and their implications for specific
dataflow analyses under consideration (unlike Khedker [67]). For new or arbitrary dataflow prob-
lems, such change-impact relationship depends on the semantics of the abstract domain, and must
be manually provided by the analysis writers, making automation difficult, and incrementalization
error-prone. The lack of formal correctness proofs in many approaches casts further doubt on
their applicability to new dataflow problems.
Given these limitations, it is not surprising that mainstream compilers, such as LLVM [74, 78],
GCC [40, 127], Soot [124, 136], Rose [99], JIT compilers (OpenJ9 [57], HotSpot [94], V8 [43]), and so
on, do not implement a framework that automatically generates incremental versions of arbitrary
IDFAs without sacrificing precision guarantees. This leaves analysis writers with two options:
design their own ad hoc incremental variants for various standard and custom analyses, which is
cumbersome and error-prone, or resort to exhaustive recomputation of dataflow solutions, which
is cost-prohibitive. Fig. 1 illustrates two such scenarios from real-world compilers, LLVM and GCC.
Snippet 1a demonstrates the error-prone nature of ad hoc incremental update implementations
– the commit summary, and the lines marked with “-” and “+”, indicate relevant bug-fixes in an
1 In
this section, we focus solely on incrementalization schemes for iterative methods for full dataflow analysis. Other
approaches, such as logic-programming-based, elimination-based, or demand-driven methods are discussed in Section 7.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:3

/* Commit Summary ( b323f4f )

* [ LoopRotate ] Fix DomTree update logic for unreachable nodes . Fix PR33701 .
* LoopRotate manually updates the DoomTree by iterating over all predecessors of a basic
block & computing the Nearest Common Dominator . When a predecessor happens to be
unreachable , `DT . findNearestCommonDominator ` returns nullptr .
* This patch teaches LoopRotate to handle this case and fixes PR33701 . */
...
// Brute force incremental dominator tree update . Call findNearestCommonDominator on all
// CFG predecessors of each child of the original header .
do {
Changed = false ;
for ( unsigned I = 0 , E = HeaderChildren . size () ; I != E ; ++ I ) { ...
- pred_iterator PI = pred_begin(BB); BasicBlock ∗NearestDom = ∗PI;
- for (pred_iterator PE = pred_end(BB); PI != PE; ++PI)
- NearestDom = DT->findNearestCommonDominator(NearestDom, ∗PI);
+ BasicBlock *NearestDom = nullptr;
+ for (BasicBlock *Pred : predecessors(BB)) {
+ // Consider only reachable basic blocks.
+ if (!DT->getNode(Pred)) continue;
+ ...
+ NearestDom = DT->findNearestCommonDominator(NearestDom, Pred);
+ } ...
}
// If the dominator changed , this may have an effect on other predecessors ,
// continue until we reach a fixpoint .
} while ( Changed ) ;
(a) LoopRotation.cpp:469-515 (LLVM), showing a bug-fixing commit; multi-line comments are the commit-message.

// We do not update postdominators , so free them unconditionally .

free_dominance_info ( CDI_POST_DOMINATORS ) ;
// If we removed paths in the CFG , then we need to update dominators as well .
// I haven 't investigated the possibility of incrementally updating dominators .
if ( cfg_altered ) free_dominance_info ( CDI_DOMINATORS ) ;
(b) tree-ssa-dce.c:1693-1711 (GCC), where the comments show the need for a generic incremental IDFA.

Fig. 1. Example snippets from LLVM and GCC, illustrating the need for a generic incremental iterative
dataflow algorithm. The comments are written by the pass writers.
LLVM commit [77]. Snippet 1b reveals how developers resort to invalidating (and later, exhaustively
recomputing) the dataflow solutions due to the lack of an incremental update mechanism in GCC.
Proposed solution. To address these challenges, we introduce IncIDFA, a novel algorithm that
provides a precise and efficient incremental version of any monotone IDFA. IncIDFA ensures from-
scratch precision using a methodical two-pass approach on each strongly-connected component
(SCC) of the program in topological order. The first pass, termed initialization-pass, efficiently
updates the dataflow solution to a state that guarantees no loss of precision. Unlike prior two-pass
approaches [42, 97, 150], IncIDFA avoids resetting the dataflow solutions to least informative values
when dealing with strongly-connected regions and arbitrary program changes. The second pass,
stabilization, derives the final fixed-point solution by applying the standard iterative method. To
prove that the final solution is the maximum fixed-point (MFP) solution, we also present a formal
description of IncIDFA, proving its soundness and precision guarantees for any monotone IDFA
with arbitrary lattices and dataflow functions. IncIDFA is fully automated, requiring only the
standard definition of the exhaustive IDFA.
It is important to clarify that this manuscript does not aim to propose a compiler design that
identifies (i) when to trigger the incremental update of a specific dataflow solution, or (ii) which
program changes to handle during such triggers. Instead, our goal is to present a generic incremental
update algorithm that can be instantiated to various specific incremental IDFAs, which can then be
invoked by any compiler framework at appropriate compilation points with required arguments.
Contributions.
• We propose IncIDFA, a generic algorithm for fully automated incrementalization of any mono-

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:4 Nougrahiya and Nandivada

tone unidirectional IDFA with arbitrary abstract domain, handling arbitrary program changes.
IncIDFA guarantees that the obtained solution matches the maximum fixed-point (MFP) solution.
• We provide a formal description of IncIDFA, along with proofs for its soundness and precision
guarantees. The proofs ascertain the applicability of IncIDFA to any monotone unidirectional IDFA
with arbitrary dataflow functions and lattices (including infinite-height lattices with widening
operators, such as those used in interval-domains).
• We introduce a novel heuristic, termed accessed-keys heuristic, to further reduce the frequency
of transfer-function applications. This heuristic proposes an option to avoid invoking transfer
functions, when the relevant portions of the incoming flow-map remain unchanged since after the
last processing of a node (a common case).
• We have implemented IncIDFA in the self-stabilizing [93] IMOP compiler framework [92] for
OpenMP C programs. We have also created ten concrete instantiations of IncIDFA, without requir-
ing any additional incrementalization-specific code for them, thereby reaffirming its generality.
• We evaluated IncIDFA using a set of real-world optimization passes (BarrElim; see [93]) on
13 benchmark programs from three standard OpenMP C suites (NPB-OMP 3.0 [139], SPEC OMP
2001 [8], and Sequoia [119]). Across two architectures, our evaluation shows up to 11× speedup
(geomean 2.6×) in IDFA-update time, and up to to 46% improvement (geomean 15.1%) in the total
compilation time, when using IncIDFA as compared to exhaustive rerun of the dataflow analyses.

2 BACKGROUND AND TERMINOLOGY

In this section, we informally describe a few key concepts used in the paper.
A flowgraph statically captures the runtime behaviour of a program, with nodes representing
units of computation (such as basic blocks in control-flow graphs, or functions in call-graphs),
and edges representing the flow of control. For simplicity, we assume that each node is unique,
contains a single statement or predicate, and is immutable. Note that immutability is not a limiting
assumption: mutations can be modeled by replacing the old node with a modified one.
Iterative Dataflow Analysis (IDFA) computes meaningful information (called flow-facts) at each
node of the flowgraph by propagating data across the flowgraph until a fixed-point is reached. Each
node 𝑛 has. two flow-facts: IN𝑛 and OUT𝑛 . The dataflow. equations for IDFA are standard [70, 87]:
IN𝑛 := 𝑝 ∈pred(𝑛) OUT𝑝 , and OUT𝑛 := 𝜏𝑛 (IN𝑛 ), where is the meet operation defined by the
associated lattice, and 𝜏𝑛 is the transfer-function of 𝑛, reflecting its impact on IN𝑛 . Informally, the
least fixed-point solution of these equations, starting with the uninitialized value (⊤) for all nodes, is
called the maximum fixed-point (MFP) solution. Any solution that, when applying the equations
until fixed-point, converges to the MFP solution, is regarded as a safe-initial-estimate. Without
loss of generality, we focus solely on forward-dataflow analyses. All results in this manuscript
apply analogously to backward-dataflow analyses as well.
Program changes obtained upon transforming a flowgraph 𝑃 to 𝑃 ′ can be defined using four
sets: (i) nodes added, (ii) nodes removed, (iii) edges added, and (iv) edges removed. For the given
program changes, the set of seed nodes contains those that may be directly impacted (that is,
require recalculation) due to the changes. For forward IDFAs, this set includes (i) newly-added nodes,
and (ii) nodes whose predecessors-set, pred, has changed. We use the term IDFA-stabilization to
refer to updating the stale dataflow solution to conform to the modified program 𝑃 ′ . Let 𝑣 be the
fixed-point solution for the original program 𝑃. To compute the new fixed-point 𝑣 ′ for 𝑃 ′ , there
are naturally two options: (i) complete invalidation and re-computation (CompIDFA) of fixed-point
solution 𝑣 ′ by applying the exhaustive IDFA on 𝑃 ′ from scratch, or (ii) incremental update, where
𝑣 ′ is computed from 𝑣, by taking the program changes into consideration. Incremental updates
generally involve fewer computations, and are thus expected to be faster.
Restarting iterations is one of the simplest approaches to incremental updates [27, 42, 90, 137,

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:5

Node OUT map

y =2; N0 {y:2}
for ( z =0; z <10; z ++) { N1 {z:0, y:2}
L1 : ...
N2 {z:⊥, y:⊥}
L2 : y = ident ( y ) ;
} N3 {z:⊥, y:⊥}
L3 : print y ; N4 {z:⊥, y:⊥}
... N5 {z:⊥, y:⊥}
N6 {z:⊥, y:⊥}
(a) Input code (b) CFG of the input program.
(c) MFP for Fig. 2b
Node OUT map Node OUT map
N0 {y:2} N0 {y:2}
N1 {z:0, y:2} N1 {z:0, y:2}
N2 {z:⊥, y:⊥} N2 {z:⊥, y:2}
N3 {z:⊥, y:⊥} N3 {z:⊥, y:2}

N5 {z:⊥, y:⊥} N5 {z:⊥, y:2}

N6 {z:⊥, y:⊥} N6 {z:⊥, y:2}

(d) CFG after eliding N4. (e) Imprecise fixed-point for Fig. 2d (f) MFP for Fig. 2d
Fig. 2. An example to illustrate the imprecision issues with restarting-iterations. Fig. 2a shows an input
program, Fig. 2b shows its control-flow graph (CFG), and Fig. 2d shows the CFG after eliding N4. Fig. 2c and
Fig. 2f show the constant-propagation MFP flow maps at various nodes, for Fig. 2b and Fig. 2d, respectively.
Fig. 2e shows the imprecise fixed-point flowmaps obtained using restarting iterations for Fig. 2d.
138], where the standard IDFA is restarted from the seed nodes to reach a fixed-point solution. This
technique produces sound but often imprecise solutions [16], as shown in Section 3.1. While Ryder
et al. [108] outlined sufficient conditions under which this technique obtains precise solutions, the
conditions are impractical since they require prior knowledge of the new solution [83].
3 INTUITION FOR INCIDFA
In this section, we first explore the causes of imprecision in restarting iterations (Section 3.1). We
then gradually build the intuition for the proposed IncIDFA algorithm in Sections 3.2, 3.3, and 3.4,
before giving a formal description of IncIDFA in Section 4.
3.1 Ghost Mappings: Imprecision Issues with Restarting Iterations
Though the restarting-iterations approach (see Section 2) for incrementalizing an IDFA is typically
faster than CompIDFA (see Section 2), it may produce imprecise results in practice. We now discuss
these imprecision issues by demonstrating the problem of ghost mappings.
Example 3.1 (Ghost Mappings). Consider the example program shown in Fig. 2a, along with its
control-flow graph (CFG) in Fig. 2b. Let us assume that the code at L1 does not write to the variable
y. The compiler derives the MFP solution at each program node for intra-procedural flow-sensitive
constant-propagation analysis [87] as shown in Fig. 2c. Note that at L2 the intra-procedural analysis
assigns ⊥ to 𝑦. Later, if the compiler determines that the function ‘ident’ is an identity function,
then a compiler pass may identify the assignment at L2 as redundant and elide it, resulting in the
removal of node N4 from the CFG. This changes the immediate predecessor of node N5 to node N3,
making the set of seed-nodes due to this transformation {N5}.
As discussed in Section 2, the restarting-iterations approach resumes the standard IDFA algorithm
with the seed-nodes ({N5}), keeping the existing OUT maps of all nodes unchanged. When processing
N5, its new IN is computed from the OUT of its predecessor (N3). However, since the OUT of N3 still
holds the stale value for y (⊥), the new IN(y) and OUT(y) for N5 do not change during this pass of
restarting-iterations, resulting in an imprecise fixed-point solution that is not the MFP solution

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:6 Nougrahiya and Nandivada

Node OUT map

N0 {y:2}
N1 {z:0, y:2}
N2 {z:⊤, y:⊤}
N3 {z:⊤, y:⊤}
N4 {}
N5 {z:⊤, y:⊤}
N6 {z:⊤, y:⊤}
(a) Result of
the first-pass of (b) Example for Section 3.3 (c) Example for the second op-
Proposal A on Fig. 2d. and Section 3.4. timization in Section 3.4.
Fig. 3. A flow-map, and various example CFG snippets (and their SDG) used in Section 3. In these examples,
node 𝑠 is the seed-node. Nodes with a ✓ have been visited, and those in concentric circles have been marked.
(shown in Fig. 2e and Fig. 2f, respectively). Consequently, the compiler cannot replace the variable
y with the literal constant 2 at L3. □
Notably, there is no node in Fig. 2d that assigns ⊥ to y, yet this mapping appears in the OUT
flowmap of all nodes within the cycle N2 → N3 → N5 → N2, as well as in node N6. We term such
mappings in the affected flowmaps as ghost mappings.
Let us understand why ghost mappings exist in the fixed-point solution obtained using the
restarting-iterations approach: While processing a node (say 𝑛) with this approach, the new IN
flowmap for 𝑛 is obtained by taking the meet of the OUT flowmaps of all its predecessors. If a
predecessor 𝑝 of node 𝑛 is reachable from any of the seed-nodes, the OUT flowmap of 𝑝 might not
correspond to a safe-initial-estimate (see Section 2) until 𝑝 itself has been processed at least once.
Hence, if node 𝑛 is processed before node 𝑝, the new IN flowmap for 𝑛 may become an unsafe-initial-
estimate due to the stale OUT flowmap of node 𝑝. When node 𝑛 and 𝑝 are part of a cycle in the CFG,
the order of processing of nodes does not resolve the issue, allowing the unsafe-initial-estimate to
propagate within the cycle, leading to ghost mappings. This is the root cause of imprecision in the
final fixed-point solution obtained using the restarting-iterations approach.
3.2 Ensuring Precision with Naïve Two-Pass Approach
Observation A. The presence of cycles in the control flow graph (CFG) can cause unsafe-initial-
estimates to propagate during incremental updates, leading to the occurrences of ghost mappings.
Proposal A: Naïve InitRestart Approach. This naïve two-pass approach is based on the
observation that the IN and OUT flowmaps of only those nodes may get updated in the final MFP
solution that are reachable from any of the seed-nodes. In the first pass, the OUT flowmaps of all
nodes reachable from the seed-nodes are reset to map all domain-elements to the initial value (⊤).
In the second pass, the restarting-iterations approach is applied until fixed-point is reached.
Note that the OUT flowmaps from the first pass are trivially safe-initial-estimates. Since there are
no unsafe-initial-estimates, ghost mappings cannot occur in the final solution. Hence, the obtained
fixed-point solution is also the maximum fixed-point (MFP) solution.
Example 3.2. Revisiting the compilation in Fig. 2, when the compiler uses Proposal A to update
the dataflow solution for Fig. 2d, it correctly computes the MFP in Fig. 2f. The nodes reachable
from seed-node N5 are {N2, N3, N6, N5}. In the first-pass, the OUT flowmaps for these nodes are
reset to map all domain-elements to ⊤, as shown in Fig. 3a. With these safe-initial-estimates, the
MFP solution shown in Fig. 2f is obtained in the second-pass, enabling the compiler to replace 𝑦
with the literal constant 2 in node N6. □
Although this proposal obtains the MFP solution by reusing a part of the existing dataflow solution

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:7

(for unreachable nodes from the seed-nodes), it may still be inefficient: Starting from the seed-nodes
(which can even occur at the beginning of the CFG), this proposal resembles CompIDFA. In fact, due
to the additional first-pass, this proposal may perform even worse than CompIDFA.
3.3 Utilizing SCC Decomposition Graphs for Efficiency
Observation B. Proposal A can lead to redundant processing of many nodes due to naïve resetting
of the OUT flowmaps of all nodes reachable from the seed-nodes, as well as due to the order in which
these nodes are processed. We illustrate the first part of this observation with an example.
Example 3.3. Consider a CFG snippet shown in Fig. 3b. Let {𝑠} be the set of seed-nodes. The dashed
ovals in the figure represent two SCCs S1 and S2 from the CFG. In the first-pass of Proposal A, all
nodes reachable from 𝑠 are reset. Assume that after reaching the fixed point within S1, the OUT
flowmap for node 𝑎 remains same as its old OUT flowmap (before the first pass). In that case, the
OUT flowmaps of node 𝑏 and beyond require no change (compared to their OUT flowmaps before
the first pass). Yet, with Proposal A, nodes in S2 and beyond are redundantly processed since they
were eagerly reset. □
Proposal B: InitRestart-SCC. To reduce the number of nodes processed, in this approach we
selectively process one SCC at a time. Recall that the issue of ghost mappings originates due to
the propagation of unsafe-initial-estimates within the cycles of a CFG. All cycles are contained
within individual SCCs of the SDG. Further, the SDG of a CFG is always a directed-acyclic graph.
Hence, by processing SCCs in topological sort order (an order popularized by Horwitz et al. [53]),
no unsafe-initial-estimates from an unprocessed SCC can pollute the solution.
In Proposal B, an SCC is processed only if it contains seed nodes or if any entry node’s IN flowmap
has changed. The processing happens in two steps – (i) initialization-step: first, the OUT flowmaps of
all nodes in the SCC are reset to map all the domain-elements to ⊤ (a trivially safe-initial-estimate),
and (ii) stabilization-step: the standard IDFA processing is applied on all nodes within the SCC until
the fixed-point is reached within the SCC. Upon reaching the fixed-point within the SCC, if the
OUT flowmap of any of its exit nodes differs from its value before the initialization-step, then the
corresponding successor SCCs are marked for processing. This solution avoids processing any SCC
more than once and also minimizes the number of SCCs processed compared to Proposal A.
Example 3.4. For the CFG in Fig. 3b, Proposal B will first process the SCC S1 (which contains the
seed-node 𝑠) as follows: The OUT flowmaps of nodes 𝑒, 𝑠, and 𝑎 are reset to map all the domain-
elements to ⊤. Standard IDFA processing is then applied on these three nodes until fixed-point.
Since the OUT flowmap of node 𝑎 does not change from its value before the initialization-step, SCC
S2 (and beyond) is not processed, thereby reducing the overheads. □
3.4 IncIDFA: Optimized Two-Pass Approach per SCC
Observation C. The size of an SCC can be quite large, leading to significant overheads in Proposal B,
since the amount of work done within an SCC is similar to that in the full-recomputation approach.
This is due to the naïve initialization-step, which resets OUT flowmaps of all the nodes in the SCC.
These overheads can be reduced if MFP solution within each SCC is obtained incrementally, without
resetting the OUT flowmaps of all the nodes.
Proposal C: IncIDFA. In this proposal, we discuss two optimizations to speed up the initialization-
step and another optimization for the stabilization-step.
3.4.1 Optimizing the initialization-step I/II. Instead of resetting all OUT flowmaps, we can use a
worklist-based initialization-step. The worklist starts with the seed nodes in the SCC and any entry
nodes of the SCC whose IN flowmaps may change due to updates in the predecessor SCCs. When
processing a node 𝑛 from the worklist, we can still obtain a safe-initial-estimate for 𝑛, if we ensure
that during the calculation of the new IN flowmap, the OUT flowmap for those predecessors of

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:8 Nougrahiya and Nandivada

𝑛 are ignored which (i) are present within the same SCC as 𝑛, and (ii) have not been processed
even once during this incremental update. This ensures that while the flowmaps of 𝑛 may be an
under-approximation, they will still be safe-initial-estimates. If the OUT flowmap of 𝑛 changes,
its unprocessed successors from the same SCC are added to the worklist. Note that any node is
processed at most once in the initialization-step. We demonstrate this optimization with an example.
Example 3.5. Let us revisit the CFG snippet shown in Fig. 3b. As compared to Proposal B, the
initialization-step for SCC S1 changes with this optimization: The OUT flowmaps of nodes 𝑒, 𝑠, and
𝑎, are not reset. The worklist is initialized with the seed-node 𝑠. When calculating the new IN
flowmap for 𝑠, the OUT flowmap of node 𝑎 is ignored as 𝑎 has not been processed yet. This trivially
makes the IN and OUT flowmaps of 𝑠 safe-initial-estimates. Let us assume that the OUT flowmap of
𝑠 does not change from its value before the initialization-step. In this case, the worklist remains
empty, and the initialization-step terminates. Note that in contrast with Proposal B, nodes 𝑒 and 𝑎
are not redundantly processed. In case the OUT flowmap of 𝑠 changes from its previous value, node
𝑒 would be added to the worklist, and the processing will continue until the worklist is empty. □
3.4.2 Optimizing the initialization-step II/II. When processing an entry node of an SCC in the first
pass, at least one safe OUT flowmap is guaranteed to be available via its predecessors from the
earlier SCCs. In contrast, for a seed-node (if not also an entry node), it is possible that none of the
OUT flowmaps of the predecessors are safe. Thus, the domain-elements of the new IN flowmaps
of such seed-nodes will be initially mapped to ⊤. This may significantly under-approximate the
flowmaps of nodes being processed in the initialization-step, thereby increasing the number of
times various nodes will have to be processed during the stabilization-step.
To address this challenge, we perform the initialization-step in two different phases, namely PhA
and PhB. In the first phase, PhA, we unconditionally process all the nodes between the entry nodes
and the seed-nodes exactly once, in their topological-sort order in the SCC. This guarantees that
at least one safe OUT flowmap will be available to the seed nodes in the second phase. In PhB, we
simply process the nodes starting with the seed-nodes as per optimization “I/II”. To reduce the
overheads while processing a node 𝑛 in PhA, we avoid invoking its transfer function if the OUT
flowmaps of all its predecessors are safe and unchanged, as illustrated next.
Example 3.6. Let us consider the CFG snippet shown in Fig. 3c. As per this optimization, we
process all the nodes starting the entry node 𝑒, up until the seed node 𝑠. Let us assume that the OUT
flowmaps of nodes 𝑎 and 𝑏 do not change. Regardless, node 𝑐 is added to the worklist. However,
since both the predecessors of 𝑐 provide safe and unchanged OUT flowmaps, we do not invoke its
transfer function. Note that the flowmaps of node 𝑑 are recalculated as one of its predecessors,
node 𝑞, is unsafe. Now since 𝑑 has been visited, the new IN flowmap of node 𝑠 will not map its
domain-elements with the init-value ⊤.
Further, let us assume that the OUT flowmap of node 𝑝 does not change upon processing. The
initialization-step will end with the processing of node 𝑝; subsequent nodes like 𝑞 and 𝑟 will not
need to be processed to be considered safe. On the other hand, even if the OUT flowmap of node 𝑝
changes, it is more likely that due to the non-⊤ IN flowmap of 𝑠, the nodes starting 𝑝 and beyond
within the SCC will need to be processed fewer times in the stabilization-step. □
Note that compared to this proposed optimization, a naïve approach of simply adding all the entry
nodes of the SCC to the worklist (along with the seed-nodes) will not suffice: when processing a
seed-node there will be no guarantee that the OUT flowmaps of at least one of its predecessor is
safe. This can also be observed for the CFG shown in Fig. 3c, where with the naïve approach the
new IN flowmap of node 𝑠 will be initially mapped to ⊤.
3.4.3 Optimizing the stabilization-step. We observe that for certain nodes, the modified
initialization-step (as per the first optimization) ignores the OUT flowmaps of one or more of

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:9

their predecessors; consequently the IN flowmaps of such nodes may be under-approximated. We

utilize this observation to speedup the stabilization-step: instead of starting the stabilization-step
by redundantly populating the worklist with all the nodes of the SCC, we populate the worklist
with only such under-approximated nodes. Note that at the beginning of the stabilization-step,
the remaining nodes within the current SCC are not added to the worklist, as reprocessing them
(in the absence of any changes to the OUT flowmaps of their predecessors) is redundant and will
not change their flowmaps. The rest of the stabilization-step continues as before. We refer to the
processing in this step as phase PhC in Section 4.
With our proposed fixes, we ensure that minimal work is needed to achieve MFP solution during
incremental update within each SCC, and hence, across the whole CFG.
4 FORMAL DESCRIPTION AND CORRECTNESS OF INCIDFA
In Section 4.1, we formalize key concepts related to IDFA and its incrementalization, as relevant to
this formalism. We present a formal description of IncIDFA in Section 4.2. In Section 4.3, we provide
proofs for its termination, soundness, and precision guarantees. For the sake of completeness, we
also present a formal model of CompIDFA in Appendix A.2.
4.1 Background and Terminology, Formally
In this section, we formalize fundamental concepts related to IDFA and its incrementalization. The
formalism is given for forward-IDFAs; results for backward-IDFAs are analogous.
Flowgraph. Each program is represented as a flowgraph, 𝑃𝑖 = (𝑁𝑖 , 𝐸𝑖 , 𝑛 0 ), where 𝑁𝑖 is the set
of basic block nodes, 𝐸𝑖 ⊆ 𝑁𝑖 × 𝑁𝑖 is the set of edges denoting the control flow, and 𝑛 0 ∈ 𝑁𝑖 is
the entry node of the program. The set of all possible nodes is denoted by N . The successors and
predecessors of a node 𝑛 in the flowgraph 𝑃𝑖 are denoted by succ𝑃𝑖 (𝑛) and pred𝑃𝑖 (𝑛), respectively.
Strongly connected components. Let SDG𝑃 denote the SCC Decomposition Graph of the flow-
graph 𝑃 = (𝑁 , 𝐸, 𝑛 0 ); for simplicity, we assume that each node which is not part of any cycle
corresponds to a singleton SCC. We denote the number of SCC-nodes in SDG𝑃 by |SDG𝑃 |. The SCC
at 𝑘 th -index in the topological sort ordering (0-indexed) of the SDG𝑃 is denoted by scc𝑃 (𝑘). The set
of program nodes in scc𝑃 (𝑘) is denoted by sccNodes𝑃 (𝑘), and its set of entry-nodes is defined as fol-
lows: sccEntryNodes𝑃 (𝑘) = {𝑛 ∈ sccNodes𝑃 (𝑘)|∃𝑚 ∈ pred𝑃 (𝑛), 𝑚 ∉ sccNodes𝑃 (𝑘)}. Informally,
entry-nodes of an SCC refer to those program nodes which have at least one predecessor from some
other SCC; exit-nodes are defined analogously. For a given node, say 𝑛, the index of its SCC in the
topological sort order of SDG𝑃 is denoted by sccID𝑃 (𝑛), that is, ∀𝑛 ∈ sccNodes𝑃 (𝑘), sccID𝑃 (𝑛) = 𝑘.
The set of successors and predecessors of 𝑛 that are present in the same SCC as that of 𝑛, are
represented by sameSccSucc𝑃 (𝑛) and sameSccPred𝑃 (𝑛), respectively.
Dataflow analysis and solution.
Definition 4.1 (Dataflow analysis). A dataflow analysis is defined as a 3-tuple, A = (L, F , M),
where
• L = (𝑉 , ⊓, ⊤, ⊥, ⊑ ) is a bounded lattice consisting of set 𝑉 of dataflow facts associated with
the analysis A, the binary meet operation ⊓, the top element ⊤, the bottom element ⊥ and the
partial order ⊑ induced by ⊓ on the elements of 𝑉 .
• F denotes the set of all monotonic functions on the lattice. A function 𝑓 : 𝑉 → 𝑉 is monotonic
if ∀𝑎, 𝑏 ∈ 𝑉 , 𝑎 ⊑ 𝑏 ⇒ 𝑓 (𝑎) ⊑ 𝑓 (𝑏).
• M : N → F maps each node of the language to some function in F . For any node 𝑛, M(𝑛)
is termed as the transfer function or flow function of 𝑛.
Definition 4.2 (Analysis instance). An analysis instance of a dataflow analysis is a 2-tuple,
A = (𝑃, 𝜗𝑒 ), where,
• 𝑃 = (𝑁 , 𝐸, 𝑛 0 ) is the flowgraph of program on which the analysis is being performed.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:10 Nougrahiya and Nandivada

• 𝜗𝑒 is the value of dataflow fact available at the beginning of the entry node 𝑛 0 .
Definition 4.3 (Dataflow state). Consider a dataflow analysis A = (L, F , M), and its analysis
instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). We define a dataflow state of A to be a 2-tuple,
𝑑 = (IN, OUT), where, IN : 𝑁 → 𝑉 , and OUT : 𝑁 → 𝑉 , map each node to its dataflow facts. Note:
storing only IN or OUT suffices in practice, for simplicity in this formalism, we maintain both.
Definition 4.4 (Fixed-point solution). Consider a dataflow analysis A = (L, F , M), and its analysis
instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). A dataflow state, 𝑑 fp = (INfp, OUTfp ), is a fixed-point
solution of A, if the following hold ∀𝑛 ∈ 𝑁 :

𝜗𝑒, if 𝑛 = 𝑛 0
.


INfp (𝑛) =
 OUTfp (𝑝), otherwise OUTfp (𝑛) = 𝜏𝑛 (INfp (𝑛)), where 𝜏𝑛 = M(𝑛)
𝑝 ∈pred𝑃 (𝑛)

Note that an analysis instance may have multiple fixed-point solutions.
Definition 4.5 (Maximum fixed-point solution). Consider a dataflow analysis A = (L, F , M), and
its analysis instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). We term a fixed-point solution of A, say
𝑑 mfp = (INmfp, OUTmfp ), as its maximum fixed-point (MFP) solution if for every other fixed-point
solution of A, say 𝑑 ′ = (IN′, OUT′ ) ≠ 𝑑 mfp , the following holds: ∀𝑛 ∈ 𝑁 , IN′ (𝑛) ⊑ INmfp (𝑛), and
OUT′ (𝑛) ⊑ OUTmfp (𝑛).
Note that each analysis instance, A, has a unique MFP solution, denoted by mfp(A).
Worklists. For a program 𝑃 = (𝑁 , 𝐸, 𝑛 0 ), a worklist is defined as an unordered subset of 𝑁 , as is
standard. In addition to standard operations such as union, intersection, and set-minus, we define
two special non-deterministic methods on a worklist: (i) firstNode, which returns any node from
the worklist, and (ii) firstNodeWithLeastSCCId, which returns any node 𝑛 that has the least sccId
among all nodes in the worklist. Both methods return an empty symbol, 𝜙, if the worklist is empty.
Program transformations and incremental analysis.
Definition 4.6 (Program change). Consider a program 𝑃 = (𝑁 , 𝐸, 𝑛 0 ), obtained by applying trans-
formations to an old program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ); for simplicity, we assume that the entry node
of a program cannot be changed during transformations. The program change between 𝑃 and 𝑃old
is denoted by a 4-tuple, Δ(𝑃old, 𝑃) = <𝛿 na, 𝛿 nr, 𝛿 ea, 𝛿 er >, where, to obtain 𝑃 from 𝑃old , 𝛿 na = 𝑁 \ 𝑁 old
is the minimal set of nodes added, 𝛿 nr = 𝑁 old \ 𝑁 is the minimal set of nodes removed, 𝛿 ea = 𝐸 \ 𝐸 old
is the minimal set of edges added, and 𝛿 er = 𝐸 old \ 𝐸 is the minimal set of edges removed.
Note that our proposed approach is generic enough to handle all kinds of program changes,
including structural modifications to the flowgraph.
Definition 4.7 (Seed nodes). Consider two programs 𝑃 = (𝑁 , 𝐸, 𝑛 0 ) and 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ), and
the program-change between them, say Δ(𝑃old, 𝑃) = <𝛿 na, 𝛿 nr, 𝛿 ea, 𝛿 er >. The set of seed nodes for
program change is defined as follows: seedNodes(𝑃 old, 𝑃) = 𝛿 na ∪ {𝑛 ∈ 𝑁 |(∗, 𝑛) ∈ 𝛿 er } ∪ {𝑛 ∈
𝑁 |(∗, 𝑛) ∈ 𝛿 ea }, where ∗ may represent any node in 𝑁 ∪ 𝑁 old .
Informally, any node 𝑛 which is either new, or whose predecessor-set, pred𝑃 (𝑛), has changed,
is considered a seed node. The flow-maps at these nodes are directly impacted as a result of the
transformations, and may require recalculation.
Definition 4.8 (Incremental-analysis instance). Consider a dataflow analysis A = (L, F , M)we
define an incremental-analysis instance as a 3-tuple, I = (A, seeds, 𝑑 old ), where:
• A = (𝑃, 𝜗𝑒 ) is an analysis instance of A, where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived by transform-
ing an old program 𝑃 old = (𝑁 old, 𝐸 old, 𝑛 0 ),
• seeds = seedNodes(𝑃old, 𝑃), and
• 𝑑 old is the MFP solution of the analysis instance Aold = (𝑃 old, 𝜗𝑒 ) for A.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:11

4.2 Formal Model for IncIDFA

Given an incremental-analysis instance I = (A, seeds, 𝑑 old ), as defined in Definition 4.8, the aim
of the IncIDFA algorithm is to obtain the MFP solution for A. In this section, we formally define
IncIDFA which was intuitively described in Section 3.4; we do so by expressing it as a fixed-point
application of a function, named evalInc . Note that in order to assist the compiler developers in
implementing IncIDFA in any framework, we have provided a more-readable, imperative-style,
version of the algorithm in Appendix B. As can be seen in both the formalism as well as the
algorithmic description, an analysis writer needs to provide the definitions for only the standard
IDFA (lattice, transfer-functions, etc.), in order to use IncIDFA.
We now present a formal treatment of IncIDFA by first explaining the concepts of SCC-phase,
IncIDFA-state, and initial IncIDFA-state, before presenting the evaluation rules of evalInc .
Definition 4.9 (SCC-phase). IncIDFA processes each SCC in three distinct phases, namely, PhA,
PhB, and PhC, in order. These correspond to the three phases described in Sections 3.4.2 and 3.4.3.
We term these phases as SCC-phases.
Definition 4.10 (IncIDFA-state). During application of IncIDFA, the state of the analysis, termed
IncIDFA-state, is denoted by a 9-tuple, Si𝑖 = <𝑘,𝑊𝑘 , 𝑑, S𝑘 , U𝑘 , M𝑘 , O𝑘 , ph,𝑊𝑔 >2 , where
• 𝑘 is the (0-based) index of the SCC being processed, in the topological order of the SDG,
• 𝑊𝑘 denotes an intra-SCC worklist, containing nodes from sccNodes𝑃 (𝑘) to be processed,
• 𝑑 represents the current dataflow state,
• S𝑘 ⊆ sccNodes𝑃 (𝑘) contains nodes that have been processed at least once during this incre-
mental update, and, thereby, contain safe-initial-estimates,
• U𝑘 ⊆ sccNodes𝑃 (𝑘) contains nodes for which recalculation of IN dataflow fact had ignored
the OUT dataflow fact of at least one predecessor, and hence may be under-approximated,
• M𝑘 ⊆ sccNodes𝑃 (𝑘) contains nodes whose OUT flow fact did not change upon recalculation,
• O𝑘 : sccExitNodes𝑃 (𝑘) → 𝑉 , maps each exit-node of the current SCC to its OUT dataflow fact
prior to the processing of the SCC,
• ph ∈ {PhA, PhB, PhC} denotes the current SCC-phase for the SCC being processed, and
• 𝑊𝑔 denotes a global worklist of nodes not in the current SCC, which need to be processed.
We represent the set of all IncIDFA-states by S𝐼 .
Definition 4.11 (Initial IncIDFA-state). Consider a program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ) and its
modified version 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). The initial IncIDFA-state for an incremental-analysis
instance I = (A, seeds, 𝑑 old =(INold , OUTold )), is represented as initStateIncIDFA (I) =
<𝑘,𝑊𝑘 , 𝑑 init, ∅, ∅, ∅, O𝑘 , PhA,𝑊𝑔 >, where:
𝑘 = min (sccID𝑃 (𝑠)), 𝑊𝑘 = sccEntryNodes𝑃 (𝑘), 𝑑 init = (INinit, OUTinit ),
∀𝑠 ∈seeds
∀𝑛 ∈ 𝑁 ∩ 𝑁 old, INinit (𝑛) = INold (𝑛), and OUTinit (𝑛) = OUTold (𝑛),
∀𝑛 ∈ 𝑁 \ 𝑁 old, INinit (𝑛) = OUTinit (𝑛) = ⊤,
∀𝑥 ∈ sccExitNodes𝑃 (𝑘) ∩ 𝑁 old, O𝑘 (𝑥) = OUTold (𝑥), 𝑎𝑛𝑑 𝑊𝑔 = seeds \ sccNodes𝑃 (𝑘)
This initial state ensures that IncIDFA is first applied on the least-id SCC that contains a seed-node.
Definition 4.12 (evalInc function). We formally describe the IncIDFA algorithm using a function
evalInc : S𝐼 → S𝐼 , which takes the current IncIDFA-state, and performs one step of the IncIDFA
algorithm to generate the next IncIDFA-state.
For an incremental-analysis instance, I, the application of IncIDFA algorithm can be seen as a fixed-
point application of evalInc , denoted by evalInc ∞ , on the initial IncIDFA-state initStateIncIDFA (I).
2 An easy mnemonic for the ordering of the four sets/maps, Safe, Under-approximated, Marked, and Out-maps, is SUMO.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:12 Nougrahiya and Nandivada

Si = <𝑘,𝑊𝑘 , 𝑑, S𝑘 , U𝑘 , M𝑘 , O𝑘 , PhA,𝑊𝑔 > 𝑊𝑘 ≠ ∅

𝑛 = firstNode(𝑊𝑘 ) 𝑛 ∉ seeds pred𝑃 (𝑛) ⊆ M𝑘
S𝑘 ′ = S𝑘 ∪ {𝑛} M𝑘 ′ = M𝑘 ∪ {𝑛}
𝑊𝑘′ = (𝑊𝑘 \ {𝑛}) ∪ (sameSccSucc𝑃 (𝑛) \ S𝑘 ′ \ seeds)
[PhA-Mark]
evalInc (Si) ⇒ <𝑘,𝑊𝑘′ , 𝑑, S𝑘 ′ , U𝑘 , M𝑘 ′ , O𝑘 , PhA,𝑊𝑔 >

Si = <𝑘,𝑊𝑘 , 𝑑, S𝑘 , U𝑘 , M𝑘 , O𝑘 , PhA,𝑊𝑔 > 𝑊𝑘 ≠ ∅

𝑛 = firstNode(𝑊𝑘 ) 𝑛 ∈ seeds ∨ pred𝑃 (𝑛) ⊈ M𝑘
𝑑 = (IN, OUT) 𝑄 𝑝 = (sameSccPred𝑃 (𝑛) ∩ S𝑘 ) ∪ (pred𝑃 (𝑛) \ sameSccPred𝑃 (𝑛))
𝑑 ′ = (IN′ , OUT′ ) = processNode(𝑑, 𝑛, 𝑄 𝑝 ) S𝑘 ′ = S𝑘 ∪ {𝑛}
( (
′ U𝑘 ∪ {𝑛}, if 𝑄 𝑝 ≠ pred𝑃 (𝑛) M𝑘 ∪ {𝑛}, if OUT′ (𝑛) = OUT(𝑛)
U𝑘 = M𝑘 ′ =
U𝑘 , otherwise M𝑘 , otherwise
𝑊𝑘′ = (𝑊𝑘 \ {𝑛}) ∪ (sameSccSucc𝑃 (𝑛) \ S𝑘 ′ \ seeds)
[PhA-Proc]
evalInc (Si) ⇒ <𝑘,𝑊𝑘′ , 𝑑 ′ , S𝑘 ′ , U𝑘 ′ , M𝑘 ′ , O𝑘 , PhA,𝑊𝑔 >

Si = <𝑘, ∅, 𝑑, S𝑘 , U𝑘 , M𝑘 , O𝑘 , PhA,𝑊𝑔 > 𝑊𝑘′ = ((seeds ∩ sccNodes𝑃 (𝑘)) \ S𝑘 )

[PhA-FP]
evalInc (Si) ⇒ ′
<𝑘,𝑊𝑘 , 𝑑, S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 >

Fig. 4. Evaluation rules for the evalInc function for marking or processing the nodes in PhA.
.



 OUT(𝑝), if 𝑄 ≠ ∅
𝑑 = (IN, OUT) IN𝑛′ = 𝑝 ∈𝑄

⊤

 otherwise
OUT𝑛′ = 𝜏𝑛 (IN𝑛′ ), where 𝜏𝑛 = M(𝑛) 𝑑 ′ = (IN[𝑛 ← IN𝑛′ ], OUT[𝑛 ← OUT𝑛′ ])
processNode(𝑑, 𝑛, 𝑄) = 𝑑 ′

Fig. 5. Helper function, processNode, to recalculate dataflow facts using the given set of predecessors.
The evaluation rules for the evalInc function are shown in Figs. 4-7, as discussed next.
Evaluation rules for evalInc in PhA (see Fig. 4). In phase PhA, the goal is to ensure that before
processing any seed node in PhB, at least one safe OUT flow fact is available from its predecessors.
[PhA-Mark] Given an IncIDFA-state in PhA, if the intra-SCC worklist, 𝑊𝑘 , is non-empty, the
evalInc function non-deterministically picks a node, say 𝑛, from 𝑊𝑘 . Rule [PhA-Mark] is applied
when node 𝑛 is not a seed node and all its predecessors are present in M𝑘 . In this case, recalculating
the dataflow facts of 𝑛 would not results in any changes. Hence, instead of applying the transfer
function, we simply mark 𝑛 as processed (and safe) by adding it to S𝑘 ′ (see Section 3.4.2). Further,
since the OUT dataflow fact of 𝑛 has not changed, we add 𝑛 to M𝑘 . Finally, each successor of 𝑛 in
the current SCC is unconditionally added to the intra-SCC worklist, except if the successor (i) is a
seed node, or (ii) has already been processed once during this incremental update.
[PhA-Proc] If node 𝑛 is a seed node, or has at least one predecessor that is not in 𝑀𝑘 , its dataflow
facts may require recalculation. In line with the optimization “I/II” discussed in Section 3.4.1, this
recalculation considers OUT flow facts from only those predecessors that have been processed at
least once in this incremental update. This set, 𝑄 𝑝 , includes all predecessors of 𝑛 that are either
in set S𝑘 , or are from the prior SCCs. The recalculation of dataflow facts is done using the helper
method processNode, which takes 𝑑, 𝑛, and 𝑄 𝑝 , and returns the modified dataflow state, by invoking
the flow function 𝜏𝑛 , as shown in Fig. 5. As before, node 𝑛 is added to the set S𝑘 ′ , since it has now
been processed. It is also added to the set U𝑘 ′ if even one of its predecessors was ignored during the
processing of 𝑛. Further, if the recalculated OUT dataflow fact for 𝑛 did not change from its old value,

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:13

Si = <𝑘,𝑊𝑘 , 𝑑, S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 > 𝑊𝑘 ≠ ∅ 𝑛 = firstNode(𝑊𝑘 )

𝑑 = (IN, OUT) 𝑄 𝑝 = (sameSccPred𝑃 (𝑛) ∩ S𝑘 ) ∪ (pred𝑃 (𝑛) \ sameSccPred𝑃 (𝑛))
𝑑 ′ = (IN′ , OUT′ ) = processNode(𝑑, 𝑛, 𝑄 𝑝 ) S𝑘 ′ = S𝑘 ∪ {𝑛}
(
U𝑘 ∪ {𝑛}, if 𝑄 𝑝 ≠ pred𝑃 (𝑛)
U𝑘 ′ =
U𝑘 , otherwise
(
(𝑊𝑘 \ {𝑛}) ∪ (sameSccSucc𝑃 (𝑛) \ S𝑘 ′ ), if OUT′ (𝑛) ≠ OUT(𝑛) or IN(𝑛) = ⊤
𝑊𝑘′ =
𝑊𝑘 \ {𝑛}, otherwise
[PhB-Proc]
evalInc (Si) ⇒ <𝑘,𝑊𝑘′ , 𝑑 ′ , S𝑘 ′ , U𝑘 ′ , ∅, O𝑘 , PhB,𝑊𝑔 >

Si = <𝑘, ∅, 𝑑, S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 >

[PhB-FP]
evalInc (Si) ⇒ <𝑘, U𝑘 , 𝑑, ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 >

Fig. 6. Evaluation rules for the evalInc function for processing the nodes in PhB.
then 𝑛 is added to the set M𝑘 ′ . The worklist is updated unconditionally as in rule [PhA-Mark].
[PhA-FP] If the intra-SCC worklist is empty in PhA, evalInc switches to phase PhB, initializing
the worklist with unprocessed seed nodes of the current SCC. Note: since the set M𝑘 is not used in
PhB, we simply pass an empty set.
Evaluation rules for evalInc in PhB (see Fig. 6). The goal of phase PhB is to remove all unsafe-
initial-estimates from the SCC.
[PhB-Proc] In PhB, if the intra-SCC worklist, 𝑊𝑘 , is not empty, evalInc non-deterministically
selects a node, say 𝑛, from 𝑊𝑘 . The rule [PhB-Proc] is similar to [PhA-Proc], with the main
difference being how the intra-SCC worklist is updated conditionally: Unlike [PhA-Proc], the
worklist is updated only if either the OUT dataflow fact of node 𝑛 changed, or if the IN dataflow fact
for 𝑛 was ⊤ (indicating 𝑛 is a newly added node). In this case, successors of 𝑛 that belong to the
current SCC, and have not yet been processed in this incremental update, are added to 𝑊𝑘 .
[PhB-FP] If the intra-SCC worklist is empty in PhB, evalInc switches to phase PhC, initializing
the worklist with the set U𝑘 . Since sets S𝑘 and U𝑘 are not used in PhC, we pass empty sets.
Evaluation rules for evalInc in PhC (see Fig. 7). The goal of PhC is the MFP computation.
[PhC-Proc] In PhC, if the intra-SCC worklist, 𝑊𝑘 , is non-empty, evalInc selects a node, say 𝑛, non-
deterministically from 𝑊𝑘 . Standard recalculation of dataflow facts of 𝑛, ignoring no predecessor, is
done using processNode. In case of changes to its OUT dataflow fact, the successors of 𝑛 from the
current SCC are added to 𝑊𝑘 . Note that a node may get processed multiple times in this phase.
[PhC-FP] When 𝑊𝑘 is empty in PhC, evalInc has reached a local fixed point for the current SCC.
Before processing the next SCC, the global worklist is updated as follows: for any exit-node 𝑥
whose OUT flow fact has changed from its stored value in O𝑘 (𝑥), the successors of 𝑥 not belonging
to the current SCC are added to the global worklist. If the resulting global worklist is not empty, the
index 𝑚 of the next SCC to be processed is obtained using the method firstNodeWithLeastSCCId.
Recall that this method returns any node with least SCC-id in the given list. Before processing the
SCC at index 𝑚, its nodes are removed from the global worklist, and its entry-nodes are added to
the intra-SCC worklist.
[Inc-Global-FP] In PhC, evalInc reaches a global fixed-point when: (i) both the intra-SCC and
global worklists are empty, and (ii) there are no exit-nodes whose OUT flow fact changed from their
stored values in O𝑘 . In this case, evalInc no longer alters the current IncIDFA-state.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:14 Nougrahiya and Nandivada

Si = <𝑘,𝑊𝑘 , 𝑑, ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 > 𝑊𝑘 ≠ ∅ 𝑛 = firstNode(𝑊𝑘 )

𝑑 = (IN, OUT) = 𝑑′ (IN′ , OUT′ )
= processNode(𝑑, 𝑛, pred𝑃 (𝑛))
(
′ (𝑊𝑘 \ {𝑛}) ∪ sameSccSucc𝑃 (𝑛), if OUT′ (𝑛) ≠ OUT(𝑛)
𝑊𝑘 =
𝑊𝑘 \ {𝑛}, otherwise
[PhC-Proc]
evalInc (Si) ⇒ <𝑘,𝑊𝑘′ , 𝑑 ′ , ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 >

Si = <𝑘, ∅, 𝑑, ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 > 𝑑 = (IN, OUT)

𝑅 = {𝑟 | ∃𝑥 ∈ sccExitNodes𝑃 (𝑘), O𝑘 (𝑥) ≠ OUT(𝑥) ∧ 𝑟 ∈ succ𝑃 (𝑥) \ sameSccSucc𝑃 (𝑥)}
𝑊𝑔′ = (𝑊𝑔 ∪ 𝑅) 𝑊𝑔′ ≠ ∅ 𝑓 = firstNodeWithLeastSCCId(𝑊𝑔′ ) 𝑚 = sccID𝑃 (𝑓 )
𝑊𝑚 = sccEntryNodes𝑃 (𝑚) 𝑊𝑔′′ = 𝑊𝑔′ \ sccNodes𝑃 (𝑚) ∀𝑥 ∈ sccExitNodes𝑃 (𝑚), O𝑚 (𝑥) = OUT(𝑥)
[PhC-FP]
evalInc (Si) ⇒ <𝑚,𝑊𝑚 , 𝑑, ∅, ∅, ∅, O𝑚 , PhA,𝑊𝑔′′ >

Si = <𝑘, ∅, 𝑑, ∅, ∅, ∅, O𝑘 , PhC, ∅> 𝑑 = (IN, OUT) ∀𝑥 ∈ sccExitNodes𝑃 (𝑘), O𝑘 (𝑥) = OUT(𝑥)

[Inc-Global-FP]
evalInc (Si) ⇒ Si

Fig. 7. Evaluation rules for the evalInc function for processing the nodes in PhC.
4.3 Correctness Proofs for IncIDFA
We now outline the proof methodology for ensuring correctness of IncIDFA, focusing on its
termination and precision guarantees. We show that the fixed-point application of evalInc on the
initial IncIDFA-state of the given incremental-analysis instance produces the maximum fixed-point
solution. Detailed definitions and proofs are present in Appendix A.1.
The correctness arguments for IncIDFA are based on two fundamental ideas, namely consistency
and safety, defined next.
Definition A.1 (Consistent node). Consider a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ), for some analysis
instance A = (𝑃, 𝜗𝑒 ), of a dataflow analysis A = (L, F , M). In the context of A, or some
incremental-analysis instance I = (A, seeds, 𝑑 old ), for any node 𝑛 ∈ 𝑁 , we term 𝑛 as a consistent
node with respect to 𝑑𝑖 , denoted as consistent(𝑛, 𝑑𝑖 ), if and only if the following relations hold:

𝜗𝑒, if 𝑛 = 𝑛 0
.


IN𝑖 (𝑛) = OUT (𝑝), otherwise OUT𝑖 (𝑛) = 𝜏𝑛 (IN𝑖 (𝑛)), where 𝜏𝑛 = M(𝑛)
𝑝 ∈pred𝑃 (𝑛) 𝑖


When all nodes in an SCC at index 𝑘 are consistent with respect to 𝑑𝑖 , we say that
consistentSCC(𝑘, 𝑑𝑖 ) holds.
Note that when a node is consistent with respect to a dataflow state, its dataflow facts remain
unchanged upon recalculation. Conversely, if the OUT dataflow fact changes, its successors may
become inconsistent with respect to the updated dataflow state.
Theorem A.3 (Fixed-point via consistency). A dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) is a fixed-point
solution for the analysis instance A = (𝑃, 𝜗𝑒 ), as well as for all the incremental-analysis instances of
the form I = (A, ∗, ∗), if and only if the following holds: ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ).
(The proof follows directly from Definitions 4.4 and A.1.)
Definition A.4 (Safe node). Consider a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ), for some analysis in-
stance A = (𝑃, 𝜗𝑒 ), or for some incremental-analysis instance I = (A, seeds, 𝑑 old ). Let 𝑑 mfp =
(INmfp, OUTmfp ) be the MFP solution of A. For any node 𝑛 ∈ 𝑁 , we term 𝑛 as a safe node with
respect to 𝑑𝑖 , denoted as safe(𝑛, 𝑑𝑖 ), if and only if the following holds:
INmfp (𝑛) ⊑ IN𝑖 (𝑛), and OUTmfp (𝑛) ⊑ OUT𝑖 (𝑛)
When all nodes in an SCC at index 𝑘 are safe with respect to 𝑑𝑖 , we say that safeSCC(𝑘, 𝑑𝑖 ) holds.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:15

Theorem A.7 (Maximum fixed-point as consistency and safety). A dataflow state 𝑑𝑖 =

(IN𝑖 , OUT𝑖 ) is the maximum fixed-point solution for the analysis instance A, as well as for all the
incremental-analysis instances of the form I = (A, ∗, ∗), if and only if the following holds: ∀𝑛 ∈
𝑁 , consistent(𝑛, 𝑑𝑖 ) ∧ safe(𝑛, 𝑑𝑖 ). (The proof relies on Theorem A.3 and Definitions 4.4, A.4, and 4.5.)
Lemma A.19 (PhB leads to consistent or underapproximated nodes). Consider an incremental-
analysis instance I = (A, seeds, 𝑑 old ), as discussed above. Let Si𝑖 = <𝑘, ∅, 𝑑𝑖 , S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 >
be the final state in PhB that is reached upon zero or more applications of evalInc . We note that in Si𝑖 ,
∀𝑛 ∈ sccNodes𝑃 (𝑘), consistent(𝑛, 𝑑𝑖 ) ∨ 𝑛 ∈ U𝑘 .
Lemma A.22 (PhB leads to safe nodes). Consider an incremental-analysis instance I =
(A, seeds, 𝑑 old ), as discussed above. Let Si𝑖 = <𝑘, ∅, 𝑑𝑖 , S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 > be the final state in PhB
that is reached upon zero or more applications of evalInc . We note that ∀𝑛 ∈ sccNodes𝑃 (𝑘), safe(𝑛, 𝑑𝑏 ).
Lemma A.23 (PhC leads to consistent and safe nodes). Consider an incremental-analysis
instance I = (A, seeds, 𝑑 old ), as discussed above. Let Si𝑐 = <𝑘, ∅, 𝑑𝑐 , ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 > be the
final state in PhC that is reached upon zero or more applications of evalInc . We note that ∀𝑛 ∈
sccNodes𝑃 (𝑘), safe(𝑛, 𝑑𝑐 ) ∧ consistent(𝑛, 𝑑𝑐 ).
Theorem A.26. Consider a dataflow analysis A, and its analysis instance A = (𝑃, 𝜗𝑒 ), where
𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived upon applying a sequence of one or more transformations on some
program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let Aold = (𝑃old, 𝜗𝑒 ) be an analysis instance of A for 𝑃old , and
let 𝑑 old be its MFP solution. Let seeds = seeds(𝑃old, 𝑃) represent the set of seed nodes for program
transformations from 𝑃 old to 𝑃. Given the incremental-analysis instance I = (A, seeds, 𝑑 old ), if Simfp
is the result of fixed-point application of the evalInc for I, and 𝑑 mfp is the dataflow state in Simfp , then
𝑘<|SDG𝑃 |
∀ , consistentSCC(𝑘, 𝑑 mfp ) ∧ safeSCC(𝑘, 𝑑 mfp )
𝑘=0
Corollary A.27. Consider a dataflow analysis A, and its analysis instance A = (𝑃, 𝜗𝑒 ), where
𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived upon applying a sequence of one or more transformations on some
program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let Aold = (𝑃old, 𝜗𝑒 ) be an analysis instance of A for 𝑃old , and
let 𝑑 old be its MFP solution. Let seeds = seeds(𝑃old, 𝑃) represent the set of seed nodes for program
transformations from 𝑃old to 𝑃. Given the incremental-analysis instance I = (A, seeds, 𝑑 old ), if Simfp is
the result of fixed-point application of the evalInc for I, and 𝑑 mfp is the dataflow state in Simfp then
𝑑 mfp = mfp(A).

5 DISCUSSION
In this section, we first briefly discuss a heuristic, termed accessed-keys heuristic, used by IncIDFA
to reduce the number of transfer-function applications. Then, we present a discussion on various
other interesting aspects of our proposed techniques.
Accessed-Keys Heuristic. We note that a significant portion of time spent during IDFA-
stabilization involves applying transfer functions. We propose a heuristic to reduce the frequency of
transfer-function applications, based on two observations: (i) transfer functions often modify only
a small part of the IN flowmap to produce the OUT flowmap, and (ii) in the context of incremental
updates, changes to the IN flowmap may not always necessitate application of the transfer function.
Accessed-Keys. Consider a node 𝑛. Let D be the domain of its flowmaps. For each application of
transfer-function of 𝑛, say 𝜏𝑛 , we define the set of accessed-keys, denoted as AK(𝑛), to contain
all those elements of D corresponding to which the values in flowmaps of 𝑛 may have been
accessed during the application of 𝜏𝑛 . The accessed-keys set for a node can be easily captured by
appropriately overriding the methods used to read and write from the flowmaps.
Let AK(𝑛) be the set of accessed-keys for 𝑛 during its last transfer-function application. If
no element in AK(𝑛) has changed between the old and new IN flowmaps, then: (i) for each

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:16 Nougrahiya and Nandivada

Fig. 8. Example demonstrating the accessed-key heuristics.

𝑥 ∉ AK(𝑛), the new OUT(𝑥) equals the new IN(𝑥), and (ii) for each 𝑥 ∈ AK(𝑛), the new OUT(𝑥)
equals the old OUT(𝑥). This heuristic eliminates unnecessry transfer-function applications. We
illustrate this heuristic using an example.
Example A.1. In Fig. 8a, the IN map for node 𝑛 is shown for an IDFA, where D = {𝑎, 𝑏, 𝑐, 𝑑 }.
Assume that the transfer function modifies the mappings of the domain-elements 𝑎 and 𝑏 to obtain
the OUT flowmap as shown in Fig. 8b. Also assume that mappings for domain-elements 𝑐 and 𝑑
were not read or written. So, AK(𝑛) = {a,b}. During incremental update, say the new IN map for
𝑛 is as shown in Fig. 8c. Here, say the mappings for elements in AK(𝑛) remain same as that in
the old IN flowmap. Consequently, we can apply the accessed-keys heuristic to obtain the new
OUT flowmap (shown in Fig. 8d) without applying its transfer-function, as follows: (i) For elements
in AK(𝑛), the mappings are obtained without changes from the old OUT flowmap. (ii) For the
remaining elements, the mappings are copied from the new IN flowmap to the old OUT flowmap.
Order of Processing of Nodes. Iterative dataflow algorithms typically use a worklist-based
approach, where the order in which nodes are extracted from the worklist can significantly influence
the number of times nodes are processed before reaching the maximum fixed-point solution.
Accordingly, various node ordering strategies have been studied in the literature [3, 26, 50, 53,
62, 66, 70]. As shown by Horwitz et al. [53] and Cooper et al. [26], the priority-SCC iteration (PSI)
approach, which uses a priority-queue for implementing the worklist, is the most efficient approach
in general. The PSI approach processes each SCC at a time, in the topological-sort order of the SDG.
Within each SCC, nodes are processed according to a reverse-postorder priority.
Given the efficiency of PSI, we use it for both CompIDFA as well as IncIDFA. Note that there are
two subtle differences between the PSI approaches for CompIDFA and IncIDFA: (i) in CompIDFA, the
worklist is initialized with all nodes in an SCC, whereas in IncIDFA, only seed nodes are added,
and (ii) IncIDFA includes a special first pass (initialization-pass, or PhA and PhB), where each node
is processed at most once. Consequently, even when the program changes affect all nodes in the
flowgraph, the order of processing of nodes (and hence the total number of times various nodes are
processed) may differ between the PSI approaches used by CompIDFA and IncIDFA.
Instantiation of IncIDFA. In order to assess the generality of IncIDFA, we have implemented
(i) a set of base classes in the IMOP compiler framework, each of which implements IncIDFA for
some sub-category of iterative dataflow problems, and (ii) a set of 10 instantiations of these base
classes to specific dataflow problems. Appendix C shows how our proposed IncIDFA works in the
context of parallel programs. Fig. 9 summarizes the set of classes implemented.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:17

Fig. 9. Implementation and instantiations of IncIDFA in the IMOP compiler framework. The classes shown
in bold are specific iterative dataflow problems.
In case of DataFlowAnalysis, we categorize the problems on the basis of whether their flow-facts
are implemented as maps from the set of cells (that is, the set of abstract memory locations on
stack and heap) to the set of some meaningful information. We term the type of such flow-facts
as cell-maps. Note that in this hierarchy, our proposed accessed-keys heuristic (see Section B.3)
is applicable only to those dataflow problems where the flow-facts are of type cell-maps (that is,
those which are subclasses of CellularDataFlowAnalysis).
The description of various specializations of these subclasses is shown in Fig. 9. Note that all these
instantiations automatically support incremental update of their dataflow solutions in response to
any program-changes; the incrementalization logic is provided by the base classes.
Stabilization of the Helper Analyses. The incremental update of dataflow solutions for any
iterative dataflow analysis may rely on the stabilization of analysis results of various other analyses,
which we term as helper analyses. In our implementation of CompIDFA and IncIDFA in IMOP,
one or more of the following analysis results must be stabilized before stabilizing the iterative
dataflow solutions: (i) control-flow graphs, (ii) call graphs, (iii) phase information, (iv) inter-task
and sibling-barrier edges, and (v) SCC Decomposition Graph. IMOP conforms to the self-stabilizing
compiler design, Homeostasis [93], which automatically ensures that the stabilizations are triggered
for required analysis results, at required compilation points, with required arguments. Consequently,
stabilization of these helper analyses is guaranteed by IMOP.
Modes of IDFA-stabilization. To assess the efficacy of the proposed incrementalization scheme,
we compare IncIDFA with the following stabilization modes: (i) CompIDFA, which corresponds
to reinitialization of the dataflow solutions, followed by its exhaustive recomputation using the
standard IDFA, and (ii) InitRestart, which corresponds to resetting the dataflow solution only
at those nodes that are reachable from the seed nodes, followed by application of the restarting
iterations approach (see Section 3.2). Note that InitRestart corresponds to one of the most
straight-forward approaches to realize incremental update of dataflow solutions in response to
program-changes, without losing on precision guarantees.
Further, for assessing the impact of accessed-keys heuristic, we also study a variant of IncIDFA

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:18 Nougrahiya and Nandivada

in which the heuristic is intentionally disabled; we term this configuration as IncIDFA-NAC. It is

important to note that the primary objective of our approach is is to provide a generic incremental-
ization algorithm that can be applied to any arbitrary dataflow problem. Hence, we do not compare
IncIDFA with techniques that rely on domain-specific knowledge about specific dataflow problems
(such as [24, 45, 76, 79, 82, 100, 121, 126, 143, 148, 149]).
Generating stabilization-triggers and program-changes from a real-world client. In or-
der to ensure that our evaluations do not rely on synthetically generated program-changes or
stabilization-triggers, we have used BarrElim (see Nougrahiya and Nandivada [93]), which is a
real-world set of optimization passes that is used to remove redundant barriers in OpenMP pro-
grams. Fig. 23 (in Appendix), reproduced from the paper by Nougrahiya and Nandivada [93], briefly
outlines the various components of BarrElim, namely (i) redundant barrier remover, (ii) OmpPar
expander, (iii) OmpPar merger, (iv) OmpPar-loop interchange, (v) OmpPar unswitching, (vi) variable
privatization, (vii) function inliner, (viii) scope remover, and (ix) unused-elements remover. For a
detailed discussion of these components, we refer the reader to the original paper.
6 IMPLEMENTATION AND EVALUATION
We have implemented IncIDFA in the IMOP compiler framework [92], an open-source platform for
parallel OpenMP C programs. IMOP spans over 170𝑘 lines of Java code, and has been effectively
utilized in several published works [2, 73, 86, 93, 140–142]. For empirical evaluations, we have also
incorporated support for three other IDFA-stabilization modes, namely CompIDFA, InitRestart
and IncIDFA-NAC, as discussed in Section 5. In total, the implementation of all these generic classes
spans around 7kLOC in IMOP.
To assess the generality of IncIDFA, we implemented ten specific dataflow problems (listed in
Section 5). As expected, no incrementalization-specific code was required in the implementation
of any of these ten analyses.
Experimental Setup. We empirically evaluated our proposed techniques using thirteen benchmark
programs from three popular OpenMP benchmark suites (see Fig. 10). The benchmarks include:
(i) all eight programs from NPB-OMP 3.0 suite [139], (ii) quake and art-m, the two (out of three)
OpenMP-C programs from SPEC OMP 2001 [8] that can be handled by IMOP, and (iii) all three
OpenMP C programs – amgmk, clomp, and stream – from Sequoia benchmark suite [119]. These
represent some of the largest open-source benchmarks for OpenMP C. Note that the remaining
programs from SPEC OMP 2001 and Sequoia, which contain a mix of C/C++/MPI code, are not
supported by IMOP and were excluded. Fig. 10 provides five key characteristics for each benchmark:
lines of code (Column 2), number of program-nodes and edges in the flow graph (Columns 3
and 4, respectively), number of strongly connected components (SCCs) with more than one node
(Column 5), and number of static barriers (Column 6).
In order to study the performance behaviour of IncIDFA across different hardware architectures,
we used two platforms: (i) Nanda, a 64-thread 2.3 GHz Intel Xeon Gold 5218 system with 64 GB
RAM; and (ii) K2, a 64-thread 2.3 GHz AMD Abu Dhabi system with 512 GB RAM. All reported
compilation and execution times are geometric means over 30 runs (as recommended by Georges
et al. [41]). We present our evaluations along the following three directions: (i) performance
evaluation of IncIDFA (in Section 6.1), (ii) performance impact of using the accessed-keys heuristic
(in Section 6.2), and (iii) empirical correctness of IncIDFA (in Section 6.3).
6.1 Performance Evaluation
We evaluate the efficacy of our proposed IncIDFA algorithm along the two dimensions of IDFA-
stabilization time and total compilation time, in the context of BarrElim, which includes a collection
of real-world optimization passes and dataflow analysis passes (see Section 5). Towards that goal,

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:19

1 2 3 4 5 6 7 8 9 10 11 12 13 14
CompIDFA IncIDFA-NAC

roc
e

r
#LOC

#SCC

#Trig
#Nod

#Edg

#Bar

#N-P
Bench. Nanda K2 Nanda K2
STB Tot STB Tot STB STB
NPB
1. BT 2615 4748 5016 11 47 21 134.0k 21.84 50.02 9.86 26.98 8.01 3.96
2. CG 642 1403 1485 15 31 70 89.8k 3.89 7.98 2.36 5.57 1.91 1.30
3. EP 352 775 813 9 4 2 2.0k 0.11 1.49 0.08 1.62 0.02 0.01
4. FT 899 2033 2151 10 14 45 180.9k 17.57 25.05 8.14 13.28 17.09 7.99
5. IS 333 711 762 5 4 2 1.9k 0.10 2.03 0.08 2.06 0.07 0.06
6. LU 2355 4687 4974 35 35 27 143.1k 15.47 28.41 8.21 17.13 12.10 6.30
7. MG 1278 2784 2918 6 19 205 1034.8k 95.85 113.40 44.86 56.16 91.03 43.03
8. SP 2543 5364 5744 11 72 14 80.7k 8.31 25.63 4.12 14.39 6.62 3.45
SPEC
9. quake 1489 3333 3491 9 22 30 115.7k 9.12 15.40 4.38 9.09 2.03 0.96
10. art-m 1691 1710 1791 13 4 9 123.3k 10.42 16.52 4.96 9.68 11.00 5.38
Sequoia
11. amgmk 895 1867 1949 1 5 44 215.0k 12.01 18.74 6.44 11.14 11.92 6.49
12. clomp 1605 4162 4289 6 73 61 385.2k 25.97 96.88 13.64 44.24 26.30 13.32
13. stream 331 735 762 3 12 25 14.6k 0.59 2.55 0.51 2.51 0.40 0.32

Fig. 10. Benchmark characteristics, and baseline evaluation numbers for their compilation with BarrElim. All times are
in seconds. Abbreviations: #LOC=lines of code, #Node/#Edge=number of nodes/edges in the CFG, #SCC=number of non-
singleton SCCs, #Barr=number of static barriers, #Trig=number of stabilization triggers with BarrElim, #N-Proc=number
of times nodes were processed during stabilization, STB=IDFA-stabilization time, and Tot=total compilation time.

(a) Nanda

(b) K2

Fig. 11. Speedup in IDFA stabilization-time using IncIDFA when applying the client optimization, BarrElim,
with respect to CompIDFA. Higher is better.
we take CompIDFA as our baseline, which corresponds to a naïve stabilization approach that entails
exhaustive recomputation of the dataflow solutions from scratch, on any given program change.
(A) IDFA-stabilization time. When compiling the benchmarks with BarrElim, the time spent
in IDFA-stabilization using CompIDFA is shown in Columns 9 and 11 of Fig. 10, for Nanda and K2,
respectively. Fig. 11 shows the relative speedups in IDFA-stabilization time using IncIDFA compared

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:20 Nougrahiya and Nandivada

Fig. 12. Total number of applications of transfer-functions across all stabilization triggers when performing
BarrElim optimization, for various configurations normalized with respect to the number of applications
in case of CompIDFA (set to 100). Lower is better.

to CompIDFA; for reference, we also include InitRestart. As expected, IncIDFA consistently

outperforms both CompIDFA and InitRestart modes, across both the platforms – as compared
to CompIDFA, we observe the maximum speedup of 11.0× (geomean 2.59×) for Nanda, and that of
8.0× (geomean 2.28×) for K2.
The gains in IDFA stabilization time depend upon various factors specific to the stabilization-
mode, such as (i) the number of times program nodes are processed, (ii) the number of skipped
transfer function applications using the accessed-keys heuristics, (iii) cost of processing various
nodes, and so on. In Fig. 10, Column 8 shows the number of times nodes are processed during
the stabilization with CompIDFA. The second factor (number of skipped transfer functions) is zero
for CompIDFA and InitRestart. For IncIDFA, we quantify it in Section 6.2. We do not report the
values for the third factor as it varies significantly across various nodes and benchmarks, and
hence is difficult to summarize. In Fig. 12, we show the number of transfer function applications
performed with IncIDFA and InitRestart, normalized to CompIDFA. The speedups obtained for
various benchmarks in Fig. 11 closely match the numbers shown in Fig. 12. We illustrate these
observations through an inspection of the relative performance of each stabilization mode.
IncIDFA vs. CompIDFA. IncIDFA results in significant improvements in IDFA stabilization time
as compared to CompIDFA, as shown in Fig. 11. This is largely due to a significant reduction in
the number of times nodes are processed using IncIDFA compared to CompIDFA. The maximum
speedups are observed for EP (11× in Nanda, and 8× in K2), and quake (5.84× in Nanda, and 5.61×
in K2), which is consequent upon the fact that the numbers of transfer-function applications with
IncIDFA (per 100 applications in CompIDFA) are least for the case of EP (34.4 applications) and
quake (16.3 applications). In contrast, we observe much lesser speedup gains for clomp (1.14×
in Nanda, and 1.15× in K2), owing to a relatively smaller reduction in the number of transfer-
function applications with IncIDFA (80.29 applications per 100 applications with CompIDFA). For
the case of art-m, we notice that the number of transfer function applications in case of IncIDFA
increases to 104.86 applications per 100 applications of CompIDFA. We attribute this anomaly to
the non-determinism that may arise from the differences in the order of node processing between
IncIDFA and CompIDFA stabilization modes (see Section 5). Despite this, we still achieve positive
gains in case of art-m (1.62× in Nanda, and 1.39× in K2). We speculate that a possible reason for
this behaviour is that, unlike CompIDFA, which starts with the most under-approximated value (⊤),
the initial values of flow-maps in IncIDFA may lead to faster node processing times.
IncIDFA vs. InitRestart. From Fig. 11, we note that IncIDFA consistently outperforms
InitRestart across both the platforms (except for IS in Nanda, where the performance is identical).
The maximum gain is observed for EP (4.0× in Nanda, and 3.0× in K2), due to approximately 27.86%
fewer transfer-function applications with IncIDFA. Additionally, IncIDFA avoids the overhead of
traversing the flowgraph and reinitializing the flow facts, as required in InitRestart. Fig. 12 shows
that IncIDFA generally requires fewer transfer-function applications than InitRestart, except for

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:21

(a) Nanda

(b) K2

Fig. 13. Percentage improvement in total compilation time using IncIDFA when applying the client opti-
mization, BarrElim, with respect to CompIDFA. Higher is better.
CG, IS, and art-m. The increase for these benchmarks may be due to the non-determinism in the
order of processing of nodes with IncIDFA and InitRestart. Regardless, IncIDFA outperforms
InitRestart (except for IS) with speedups of 1.15× in Nanda and 1.11× in K2 for CG; and 1.48× in
Nanda and 1.28× in K2 for art-m. The gains are largely due to the fact that a significant amount of
time in InitRestart is spent in flowgraph traversals, and reinitialization of the reachable nodes –
63% of the total stabilization time in case of CG, and 90% in case of art-m (numbers not shown).
Performance of IncIDFA in the absence of accessed-keys heuristics. In Fig. 10, Column 13 and 14
show the IDFA stabilization time with IncIDFA-NAC (that is, IncIDFA with accessed-keys heuris-
tic disabled) as compared to CompIDFA, for Nanda and K2, respectively. Comparing them with
Columns 9 and 11, respectively, we notice that even in the absence of the accessed-keys heuristic
our incrementalization approach generally outperforms CompIDFA. We discuss the performance
impact of the accessed-keys heuristic on IncIDFA in Section 6.2.
Summary. Overall, we found that in terms of IDFA-stabilization time, IncIDFA outperforms all
the other stabilization modes. These gains improve the overall compilation time, as discussed next.
(B) Total compilation time. In Fig. 10, Columns 10 and 12 show the total compilation time with
CompIDFA, when applying BarrElim on the benchmarks under study, for Nanda and K2, respectively.
This total compilation time spans from parsing the input file to applying the BarrElim optimizations
and writing the final program to disk. Fig. 13 shows the benefits of using IncIDFA compared to
CompIDFA, with InitRestart included for reference. We consider performance differences below
2% as negligible due to measurement errors. We see that with IncIDFA, the maximum and geomean
improvements with respect to CompIDFA are 46.16% and 15.08% respectively in Nanda, and 38.39%
and 11.83% respectively in K2. IncIDFA consistently outperforms both CompIDFA and InitRestart
(except for IS in Nanda, where the difference is negligible).
The gains in total compilation time depend on factors such as (i) the fraction of time spent in
IDFA stabilization (see Fig. 10, Columns 9 and 10 for Nanda, and Columns 11 and 12 for K2);
(ii) overall speedup in the IDFA-stabilization time (shown in Fig. 11), and (iii) non-deterministic
changes to the available heap size for the VM, and the associated GC overheads. This third factor is
non-deterministic and infeasible to calculate empirically.
IncIDFA vs. CompIDFA. Fig. 13 shows that IncIDFA consistently outperforms CompIDFA in terms

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:22 Nougrahiya and Nandivada

Fig. 14. Percentage improvement in IDFA stabilization-time using IncIDFA when applying the client optimization,
BarrElim, with respect to IncIDFA-NAC, which is a version of IncIDFA with accessed-keys heuristic disabled. Higher is
better.
of the total compilation time. The highest gains are for quake, where IDFA-stabilization time makes
up a significant portion of the total time (59.2% in Nanda, and 48% in K2), with IncIDFA resulting
in significant gains in the IDFA-stabilization time (5.84× in Nanda, and 5.61× in K2). Similarly, MG
sees 42.22% improvement in total time on Nanda, and 32.12% in K2, given that a significant amount
of compilation time was spent in IDFA-stabilization (84.5% in Nanda, and 79.8% in K2), which, in
turn, obtained a decent improvement with IncIDFA (2.0× in Nanda, and 1.67× in K2). In contrast,
despite the highest improvements in the IDFA stabilization time (11× in Nanda, and 8× in K2), EP
witnesses little (though significant) gains in the total compilation time (4.69% in Nanda, and 3.08%
in K2). This is unsurprising, given that only a small fraction of the total time (7.4% in Nanda, and
4.9% in K2) is spent in IDFA stabilization of EP.
IncIDFA vs. InitRestart. Except for negligible degradation for IS in Nanda, IncIDFA consistently
outperforms InitRestart. The maximum gains are noted for MG (40.9% in Nanda, and 31.4% in K2),
since a significantly large chunk of the total compilation time for MG is spent in its IDFA-stabilization,
which, in turn, had a decent gain with IncIDFA (1.96× in Nanda; 1.65× in K2).
Summary. IncIDFA offers significant gains in overall compilation time, as compared to CompIDFA
and InitRestart.
6.2 Impact of Accessed-Keys Heuristic
We evaluate the impact of accessed-keys heuristic by comparing IncIDFA with IncIDFA-NAC (the
variant with the heuristic disabled (see Section 5). For lack of space, we present the results for
only one platform (Nanda) here; the results for K2 can be found in Appendix D. Fig. 14 shows
the percentage improvement using the heuristic. We see that IncIDFA consistently outperforms
IncIDFA-NAC; improvements up to 60.7% (geomean 32.23%).
The gains from the heuristic depends upon: (i) the number of transfer-function applications
skipped, and (ii) the time spent in applying the transfer-functions when processing the nodes. We
observed a maximum reduction of 84.41% in transfer-function applications, with a geomean of
65.64% (numbers in Appendix D, Fig. 22). Note that quantifying the second factor is difficult, as it
varies significantly across different kinds of nodes and dataflow analyses.
With the accessed-keys heuristic, we notice maximum gains in case of LU (60.7%), due to a total of
80.9% skipped transfer-function applications. In contrast, IS sees a gain of only 14.28%, given that
only 48.89% of its transfer-function applications were skipped with the heuristic.
Summary. The accessed-keys heuristic significantly reduces the number of transfer-function
applications, leading to substantial improvements in the IDFA-stabilization time.
6.3 Empirical Correctness
For each stabilization mode, we used IMOP to generate output text files with final dataflow facts
annotated as comments on the nodes (statements/predicates). We verified that for all benchmarks,
the files match verbatim across stabilization modes. Further, to ensure correct stabilization during
BarrElim, we confirmed that the optimized code is identical across all stabilization modes.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:23

Overall evaluation summary. Our evaluation demonstrates that (i) IncIDFA improves IDFA-
stabilization time and overall compilation time compared to naïve stabilization schemes, (ii) the
accessed-keys heuristic is effective in further improving the compilation time, and (iii) our imple-
mentation ensures correct analysis and optimized code.
7 RELATED WORK
In Section 1, we discussed key prior works related to the incrementalization of iterative approaches
to dataflow analyses. Now we review the literature on various alternative approaches.
Elimination methods, such as structural analysis and interval analysis, work by analyzing the
control-tree of the program [5, 7, 44, 134, 135]. By exploiting the hierarchical structure of the
program, they are generally (i) faster than the iterative methods, and (ii) more amenable to efficient
incremental updates [87]. Various incrementalization schemes have been given for such methods [15,
20–22, 58, 109–111, 125]. However, elimination methods are only applicable to reducible flow-
graphs [51], limiting their use in various common scenarios, as noted by Cooper et al. [26].
Methods of attributes for dataflow analysis have been introduced by Babich and Jazayeri [10].
These methods use attribute grammars, where dataflow information is represented as attributes on
parse-tree nodes, and the transfer functions are specified as part of the production rules. Several
incremental update schemes in the context of attribute grammars have been proposed [4, 13, 14,
19, 31, 47, 56, 61, 64, 85, 101, 102, 105, 116, 144, 146, 147]. The key issue with attribute grammars is
their inability to handle programs with cyclic or arbitrary control-flows.
Logic-programming-based methods offer an orthogonal approach to dataflow analysis, differing
from the iterative techniques. These methods employ fixed-point application of logical rules and
inference mechanisms on program facts to model and solve dataflow problems. Uwe Aßmann [9] in-
troduced the idea of using Datalog for static analysis. Since then, many generic tools and extensions
to Datalog, such as Soufflé [60], Flix [81], FlowSpec [123], Flan [1], and others [6, 71, 80, 91, 118]
have been developed. Incrementalization frameworks like IncA [133], Ladder[132], and oth-
ers [35, 38, 39, 39, 52, 98, 113–115, 120, 122, 130, 131, 154] have also been proposed. While the
declarative nature of Datalog simplifies expression of complex dataflow analyses, it limits the
analysis writer’s control over the low-level computational details, as noted by Ceri et al. [23]. It
remains to be explored how our techniques could be adapted to Datalog-based methods.
Demand-driven analyses [11, 33, 54, 103, 112] focus on inspecting only the relevant parts of a
flowgraph to answer the given query. Following program edits, incremental updates are needed only
for these relevant parts when the query is issued. In many demand-driven frameworks, queries are
structured using the formalism of Context-Free Language (CFL) reachability [104], which models
various program-properties (such as points-to relations) as realizable paths in a graph, such that
the paths conform to the CFL. Various incrementalization approaches have been proposed for
such demand-driven and CFL-reachability-based analyses [36, 79, 121, 128]. We believe that it is an
interesting idea to extend our proposed ideas to demand driven analysis.

8 CONCLUSION
We presented IncIDFA, a novel algorithm that provides a generic solution for automatically gen-
erating precise incremental variants of any monotone iterative dataflow analysis. To validate the
correctness and applicability of IncIDFA for a wide range of iterative dataflow problems, we pro-
vide proofs for the soundness and precision guarantees of IncIDFA. Alongside the core algorithm,
we also presented a heuristic to reduce the number of transfer-function applications. To ensure
applicability of IncIDFA to any arbitrary abstract domain and program edits, we also provided its
formal model and correctness proofs. We implemented IncIDFA in the IMOP compiler for parallel
OpenMP C programs, and instantiated it for ten specific dataflow problems, without requiring

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:24 Nougrahiya and Nandivada

custom incremental-update code. Evaluations on a set of real-world optimization passes (BarrElim)

and standard benchmark programs showed encouraging performance, demonstrating the capa-
bilities of IncIDFA for efficiently and automatically handling incremental iterative algorithms for
arbitrary monotone dataflow problems.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:25

9 DATA-AVAILABILITY STATEMENT
We will be submitting an artifact for this manuscript, for the purpose of Artifact Evaluation. Our
implementation is open-source, however we need to anonymize it first before we can share the link.
The artifact will include the source code, benchmark programs, evaluation scripts, as well as the
graph-generation scripts necessary to reproduce the experimental results presented in this paper.
In terms of reproducibility of results, the artifact has no known limitations to our knowledge.

REFERENCES
[1] Supun Abeysinghe, Anxhelo Xhebraj, and Tiark Rompf. 2024. Flan: An Expressive and Efficient Datalog Compiler for
Program Analysis. Proc. ACM Program. Lang. 8, POPL, Article 86 (Jan. 2024), 33 pages. https://doi.org/10.1145/3632928
[2] Aditya Agrawal and V. Krishna Nandivada. 2023. UWOmppro: UWOmp++ with Point-to-Point Synchronization,
Reduction and Schedules. In 2023 32nd International Conference on Parallel Architectures and Compilation Techniques
(PACT). 27–38. https://doi.org/10.1109/PACT58117.2023.00011
[3] A. V. Aho and J. D. Ullman. 1975. Node Listings for Reducible Flow Graphs. In Proceedings of the Seventh Annual
ACM Symposium on Theory of Computing (Albuquerque, New Mexico, USA) (STOC ’75). Association for Computing
Machinery, New York, NY, USA, 177–185. https://doi.org/10.1145/800116.803767
[4] Henk Alblas. 1991. Incremental Attribute Evaluation. In Attribute Grammars, Applications and Systems, Henk Alblas
and Bo𝜗rivoj Melichar (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 215–233.
[5] F. E. Allen and J. Cocke. 1976. A Program Data Flow Analysis Procedure. Commun. ACM 19, 3 (March 1976), 137.
https://doi.org/10.1145/360018.360025
[6] Mario Alvarez-Picallo, Alex Eyers-Taylor, Michael Peyton Jones, and C.-H. Luke Ong. 2019. Fixing Incremental
Computation. In Programming Languages and Systems, Luís Caires (Ed.). Springer International Publishing, Cham,
525–552.
[7] Steven Arzt and Eric Bodden. 2014. Reviser: Efficiently Updating IDE-/IFDS-Based Data-Flow Analyses in Response to
Incremental Program Changes. In Proceedings of the 36th International Conference on Software Engineering (Hyderabad,
India) (ICSE 2014). Association for Computing Machinery, New York, NY, USA, 288–298. https://doi.org/10.1145/
2568225.2568243
[8] Vishal Aslot, Max Domeika, Rudolf Eigenmann, Greg Gaertner, Wesley B. Jones, and Bodo Parady. 2001. SPEComp: A
New Benchmark Suite for Measuring Parallel Computer Performance. In Workshop on OpenMP Applications and Tools,
Rudolf Eigenmann and Michael J. Voss (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 1–10.
[9] Uwe Aßmann. 1996. On Edge Addition Rewrite Systems and Their Relevance to Program Analysis. In Graph Grammars
and Their Application to Computer Science, Janice Cuny, Hartmut Ehrig, Gregor Engels, and Grzegorz Rozenberg
(Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 321–335.
[10] Wayne A. Babich and Mehdi Jazayeri. 1978. The Method of Attributes for Data Flow Analysis. Part I. Exhaustive
Analysis. Acta Informatica 10, 3 (1978), 245–264.
[11] Wayne A. Babich and Mehdi Jazayeri. 1978. The Method of Attributes for Data Flow Analysis. Part II. Demand
Analysis. Acta Informatica 10, 3 (1978), 265–272.
[12] Ayon Basumallik and Rudolf Eigenmann. 2008. Incorporation of OpenMP Memory Consistency into Conventional
Dataflow Analysis. In OpenMP in a New Era of Parallelism, Rudolf Eigenmann and Bronis R. de Supinski (Eds.).
Springer Berlin Heidelberg, Berlin, Heidelberg, 71–82.
[13] Jeroen Bransen, Atze Dijkstra, and S. Doaitse Swierstra. 2014. Lazy Stateless Incremental Evaluation Machinery
for Attribute Grammars. In Proceedings of the ACM SIGPLAN 2014 Workshop on Partial Evaluation and Program
Manipulation (San Diego, California, USA) (PEPM ’14). Association for Computing Machinery, New York, NY, USA,
145–156. https://doi.org/10.1145/2543728.2543735
[14] Jeroen Bransen, Atze Dijkstra, and S. Doaitse Swierstra. 2015. Incremental Evaluation of Higher Order Attributes.
In Proceedings of the 2015 Workshop on Partial Evaluation and Program Manipulation (Mumbai, India) (PEPM ’15).
Association for Computing Machinery, New York, NY, USA, 39–48. https://doi.org/10.1145/2678015.2682541
[15] Michael Burke. 1990. An Interval-Based Approach to Exhaustive and Incremental Interprocedural Data-Flow Analysis.
ACM Trans. Program. Lang. Syst. 12, 3 (Jul 1990), 341–395. https://doi.org/10.1145/78969.78963
[16] M.G. Burke and B.G. Ryder. 1990. A Critical Analysis of Incremental Iterative Data Flow Analysis Algorithms. IEEE
Transactions on Software Engineering 16, 7 (1990), 723–728. https://doi.org/10.1109/32.56098
[17] Haipeng Cai and John Jenkins. 2018. Leveraging Historical Versions of Android Apps for Efficient and Precise Taint
Analysis. In Proceedings of the 15th International Conference on Mining Software Repositories (Gothenburg, Sweden) (MSR
’18). Association for Computing Machinery, New York, NY, USA, 265–269. https://doi.org/10.1145/3196398.3196433
[18] David Callahan and Jaspal Sublok. 1988. Static Analysis of Low-Level Synchronization. SIGPLAN Not. 24, 1 (Nov

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:26 Nougrahiya and Nandivada

1988), 100–111. https://doi.org/10.1145/69215.69225

[19] Alan Carle and Lori Pollock. 1989. Modular Specification of Incremental Program Transformation Systems. In
Proceedings of the 11th International Conference on Software Engineering (Pittsburgh, Pennsylvania, USA) (ICSE ’89).
Association for Computing Machinery, New York, NY, USA, 178–187. https://doi.org/10.1145/74587.74612
[20] Martin Carroll and Barbara G Ryder. 1987. An Incremental Algorithm for Software Analysis. In Proceedings of the
Second ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments
(Palo Alto, California, USA) (SDE 2). Association for Computing Machinery, New York, NY, USA, 171–179. https:
//doi.org/10.1145/24208.24228
[21] M. D. Carroll and B. G. Ryder. 1988. Incremental Data Flow Analysis via Dominator and Attribute Update. In Proceedings
of the 15th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (San Diego, California, USA)
(POPL ’88). Association for Computing Machinery, New York, NY, USA, 274–284. https://doi.org/10.1145/73560.73584
[22] Steven Carroll and Constantine Polychronopoulos. 2004. A Framework for Incremental Extensible Compiler
Construction. International Journal of Parallel Programming 32, 4 (2004), 289–316. https://doi.org/10.1023/B:
IJPP.0000035816.93295.68
[23] S. Ceri, G. Gottlob, and L. Tanca. 1989. What You Always Wanted to Know About Datalog (And Never Dared to Ask).
IEEE Trans. on Knowl. and Data Eng. 1, 1 (March 1989), 146–166. https://doi.org/10.1109/69.43410
[24] Yuting Chen, Qiuwei Shi, and Weikai Miao. 2015. Incremental Points-to Analysis for Java via Edit Propagation. In
Structured Object-Oriented Formal Language and Method, Shaoying Liu and Zhenhua Duan (Eds.). Springer International
Publishing, Cham, 164–178.
[25] Christopher L. Conway, Kedar S. Namjoshi, Dennis Dams, and Stephen A. Edwards. 2005. Incremental Algorithms
for Inter-procedural Analysis of Safety Properties. In Computer Aided Verification, Kousha Etessami and Sriram K.
Rajamani (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 449–461.
[26] Keith D. Cooper, Timothy J. Harvey, and Ken Kennedy. 2002. Iterative Data-flow Analysis, Revisited. Technical Report.
Rice University.
[27] Keith D. Cooper and Ken Kennedy. 1984. Efficient Computation of Flow Insensitive Interprocedural Summary
Information. In Proceedings of the 1984 SIGPLAN Symposium on Compiler Construction (Montreal, Canada) (SIGPLAN
’84). Association for Computing Machinery, New York, NY, USA, 247–258. https://doi.org/10.1145/502874.502898
[28] Patrick Cousot and Radhia Cousot. 2002. Modular Static Program Analysis. In Compiler Construction, R. Nigel
Horspool (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 159–179.
[29] Leonardo Dagum and Ramesh Menon. 1998. OpenMP: an industry standard API for shared-memory programming.
Computational Science & Engineering, IEEE 5, 1 (1998), 46–55.
[30] Arnab De, Deepak D’Souza, and Rupesh Nasre. 2011. Dataflow Analysis for Datarace-Free Programs. In Programming
Languages and Systems, Gilles Barthe (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 196–215.
[31] Alan Demers, Thomas Reps, and Tim Teitelbaum. 1981. Incremental Evaluation for Attribute Grammars with
Application to Syntax-Directed Editors. In Proceedings of the 8th ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages (Williamsburg, Virginia) (POPL ’81). Association for Computing Machinery, New York, NY,
USA, 105–116. https://doi.org/10.1145/567532.567544
[32] Lisa Nguyen Quang Do, Karim Ali, Benjamin Livshits, Eric Bodden, Justin Smith, and Emerson Murphy-Hill. 2017.
Just-in-Time Static Analysis. In Proceedings of the 26th ACM SIGSOFT International Symposium on Software Testing
and Analysis (Santa Barbara, CA, USA) (ISSTA 2017). Association for Computing Machinery, New York, NY, USA,
307–317. https://doi.org/10.1145/3092703.3092705
[33] Evelyn Duesterwald, Rajiv Gupta, and Mary Lou Soffa. 1995. Demand-Driven Computation of Interprocedural
Data Flow. In Proceedings of the 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages
(San Francisco, California, USA) (POPL ’95). Association for Computing Machinery, New York, NY, USA, 37–48.
https://doi.org/10.1145/199448.199461
[34] Evelyn Duesterwald and Mary Lou Soffa. 1991. Concurrency Analysis in the Presence of Procedures Using a Data-Flow
Framework. In Proceedings of the Symposium on Testing, Analysis, and Verification (Victoria, British Columbia, Canada)
(TAV4). Association for Computing Machinery, New York, NY, USA, 36–48. https://doi.org/10.1145/120807.120811
[35] Michael Eichberg, Matthias Kahl, Diptikalyan Saha, Mira Mezini, and Klaus Ostermann. 2007. Automatic In-
crementalization of Prolog Based Static Analyses. In Proceedings of the 9th International Conference on Prac-
tical Aspects of Declarative Languages (Nice, France) (PADL’07). Springer-Verlag, Berlin, Heidelberg, 109–123.
https://doi.org/10.1007/978-3-540-69611-7_7
[36] Julian Erhard, Simmo Saan, Sarah Tilscher, Michael Schwarz, Karoliine Holter, Vesal Vojdani, and Helmut Seidl.
2024. Interactive Abstract Interpretation: Reanalyzing Multithreaded C Programs for Cheap. International Journal on
Software Tools for Technology Transfer (2024). https://doi.org/10.1007/s10009-024-00768-9
[37] István Forgács. 1994. Double Iterative Framework for Flow-Sensitive Interprocedural Data Flow Analysis. ACM Trans.
Softw. Eng. Methodol. 3, 1 (Jan 1994), 29–55. https://doi.org/10.1145/174634.174635

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:27

[38] Isabel Garcia-Contreras, Jose F. Morales, and Manuel V. Hermenegildo. 2019. Incremental Analysis of Logic Programs
with Assertions and Open Predicates. In Logic-Based Program Synthesis and Transformation: 29th International
Symposium, LOPSTR 2019, Porto, Portugal, October 8-10, 2019, Revised Selected Papers (Porto, Portugal). Springer-Verlag,
Berlin, Heidelberg, 36–56. https://doi.org/10.1007/978-3-030-45260-5_3
[39] Isabel Garcia-Contreras, Jose F. Morales, and Manuel V. Hermenegildo. 2021. Incremental and Modular Context-
Sensitive Analysis. Theory and Practice of Logic Programming 21, 2 (2021), 196–243. https://doi.org/10.1017/
S1471068420000193 arXiv:https://arxiv.org/abs/1804.01839 [cs.PL]
[40] GCC-Developer-Community. 2024. GCC GitHub Repository. Retrieved September 2, 2024 from https://github.com/gcc-
mirror/gcc
[41] Andy Georges, Dries Buytaert, and Lieven Eeckhout. 2007. Statistically Rigorous Java Performance Evaluation.
SIGPLAN Not. 42, 10 (Oct. 2007), 57–76. https://doi.org/10.1145/1297105.1297033
[42] Vida Ghoddsi. 1983. Incremental Analysis of Programs. Ph. D. Dissertation. University of Central Florida.
[43] Google. 2001. Chrome V8. https://github.com/v8/v8
[44] Susan L. Graham and Mark Wegman. 1976. A Fast and Usually Linear Algorithm for Global Flow Analysis. J. ACM
23, 1 (Jan 1976), 172–202. https://doi.org/10.1145/321921.321939
[45] William G. Griswold. 1993. Direct Update of Data Flow Representations for a Meaning-Preserving Program
Restructuring Tool. In Proceedings of the 1st ACM SIGSOFT Symposium on Foundations of Software Engineering
(Los Angeles, California, USA) (SIGSOFT ’93). Association for Computing Machinery, New York, NY, USA, 42–55.
https://doi.org/10.1145/256428.167063
[46] Dirk Grunwald and Harini Srinivasan. 1993. Data Flow Equations for Explicitly Parallel Programs. SIGPLAN Not. 28,
7 (Jul 1993), 159–168. https://doi.org/10.1145/173284.155349
[47] Rajiv Gupta and Mary Lou Soffa. 1994. A Framework for Partial Data Flow Analysis. In Proceedings of the International
Conference on Software Maintenance (ICSM ’94). IEEE Computer Society, USA, 4–13.
[48] M.J. Harrold and G. Rothermel. 1996. Separate Computation of Alias Information for Reuse. IEEE Transactions on
Software Engineering 22, 7 (1996), 442–460. https://doi.org/10.1109/32.538603
[49] Matthew S. Hecht. 1977. Flow Analysis of Computer Programs. Elsevier Science Inc., USA.
[50] Matthew S. Hecht and Jeffrey D. Ullman. 1973. Analysis of a Simple Algorithm for Global Data Flow Problems. In
Proceedings of the 1st Annual ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (Boston,
Massachusetts) (POPL ’73). Association for Computing Machinery, New York, NY, USA, 207–217. https://doi.org/10.
1145/512927.512946
[51] M. S. Hecht and J. D. Ullman. 1974. Characterizations of Reducible Flow Graphs. J. ACM 21, 3 (jul 1974), 367–375.
https://doi.org/10.1145/321832.321835
[52] Manuel Hermenegildo, German Puebla, Kim Marriott, and Peter J. Stuckey. 2000. Incremental Analysis of Constraint
Logic Programs. ACM Trans. Program. Lang. Syst. 22, 2 (Mar 2000), 187–223. https://doi.org/10.1145/349214.349216
[53] Susan Horwitz, Alan Demers, and Tim Teitelbaum. 1987. An Efficient General Iterative Algorithm for Dataflow
Analysis. Acta Informatica 24, 6 (1987), 679–694. https://doi.org/10.1007/BF00282621
[54] Susan Horwitz, Thomas Reps, and Mooly Sagiv. 1995. Demand Interprocedural Dataflow Analysis. SIGSOFT Softw.
Eng. Notes 20, 4 (Oct. 1995), 104–115. https://doi.org/10.1145/222132.222146
[55] Lei Huang, Girija Sethuraman, and Barbara Chapman. 2008. Parallel Data Flow Analysis for OpenMP Programs.
In International Workshop on OpenMP, Barbara Chapman, Weiming Zheng, Guang R. Gao, Mitsuhisa Sato, Eduard
Ayguadé, and Dongsheng Wang (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 138–142.
[56] Scott E. Hudson. 1991. Incremental Attribute Evaluation: A Flexible Algorithm for Lazy Update. ACM Trans. Program.
Lang. Syst. 13, 3 (Jul 1991), 315–341. https://doi.org/10.1145/117009.117012
[57] IBM. 2017. Eclipse OpenJ9. https://github.com/eclipse/openj9
[58] S. Jain and C. Thompson. 1988. An Efficient Approach to Data Flow Analysis in a Multiple Pass Global Optimizer. In
Proceedings of the ACM SIGPLAN 1988 Conference on Programming Language Design and Implementation (Atlanta,
Georgia, USA) (PLDI ’88). Association for Computing Machinery, New York, NY, USA, 154–163. https://doi.org/10.
1145/53990.54006
[59] Swati Jaiswal, Uday P. Khedker, and Alan Mycroft. 2021. A Unified Model for Context-Sensitive Program Analyses: The
Blind Men and the Elephant. ACM Comput. Surv. 54, 6, Article 114 (July 2021), 37 pages. https://doi.org/10.1145/3456563
[60] Herbert Jordan, Bernhard Scholz, and Pavle Subotić. 2016. Soufflé: On Synthesis of Program Analyzers. In Computer
Aided Verification, Swarat Chaudhuri and Azadeh Farzan (Eds.). Springer International Publishing, Cham, 422–430.
[61] Gail E. Kaiser and Simon M. Kaplan. 1993. Parallel and Distributed Incremental Attribute Evaluation Algorithms
for Multiuser Software Development Environments. ACM Trans. Softw. Eng. Methodol. 2, 1 (Jan 1993), 47–92.
https://doi.org/10.1145/151299.151312
[62] John B. Kam and Jeffrey D. Ullman. 1976. Global Data Flow Analysis and Iterative Algorithms. J. ACM 23, 1 (Jan
1976), 158–171. https://doi.org/10.1145/321921.321938

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:28 Nougrahiya and Nandivada

[63] John B. Kam and Jeffrey D. Ullman. 1977. Monotone Data Flow Analysis Frameworks. Acta Informatica 7, 3 (1977),
305–317. https://doi.org/10.1007/BF00290339
[64] Simon M Kaplan and Gail E Kaiser. 1986. Incremental Attribute Evaluation in Distributed Language-Based
Environments. In Proceedings of the Fifth Annual ACM Symposium on Principles of Distributed Computing (Cal-
gary, Alberta, Canada) (PODC ’86). Association for Computing Machinery, New York, NY, USA, 121–130. https:
//doi.org/10.1145/10590.10601
[65] J. Keables, K. Roberson, and A. von Mayrhauser. 1988. Data Flow Analysis and its Application to Software Maintenance.
In Proceedings. Conference on Software Maintenance, 1988. 335–347. https://doi.org/10.1109/ICSM.1988.10185
[66] K. W. Kennedy. 1975. Node Listings Applied to Data Flow Analysis. In Proceedings of the 2nd ACM SIGACT-SIGPLAN
Symposium on Principles of Programming Languages (Palo Alto, California) (POPL ’75). Association for Computing
Machinery, New York, NY, USA, 10–21. https://doi.org/10.1145/512976.512978
[67] Uday P. Khedker. 1995. A Generalised Theory of Bit Vector Data Flow Analysis. Ph. D. Dissertation.
[68] Uday P. Khedker and Dhananjay M. Dhamdhere. 1994. A Generalized Theory of Bit Vector Data Flow Analysis. ACM
Trans. Program. Lang. Syst. 16, 5 (Sept. 1994), 1472–1511. https://doi.org/10.1145/186025.186043
[69] Uday P. Khedker and Dhananjay M. Dhamdhere. 1999. Bidirectional Data Flow Analysis: Myths and Reality. SIGPLAN
Not. 34, 6 (June 1999), 47–57. https://doi.org/10.1145/606666.606676
[70] Gary A. Kildall. 1973. A Unified Approach to Global Program Optimization. In Proceedings of the 1st Annual ACM
SIGACT-SIGPLAN Symposium on Principles of Programming Languages (Boston, Massachusetts) (POPL ’73). Association
for Computing Machinery, New York, NY, USA, 194–206. https://doi.org/10.1145/512927.512945
[71] David Klopp, Sebastian Erdweg, and André Pacak. 2024. Object-Oriented Fixpoint Programming with Datalog. Proc.
ACM Program. Lang. 8, OOPSLA2, Article 273 (Oct. 2024), 27 pages. https://doi.org/10.1145/3689713
[72] Jakob Krainz and Michael Philippsen. 2017. Diff Graphs for a Fast Incremental Pointer Analysis. In Proceedings of the
12th Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems
(Barcelona, Spain) (ICOOOLPS’17). Association for Computing Machinery, New York, NY, USA, Article 4, 10 pages.
https://doi.org/10.1145/3098572.3098578
[73] Gnanambikai Krishnakumar, Kommuru Alekhya Reddy, and Chester Rebeiro. 2019. ALEXIA: A Processor with
Lightweight Extensions for Memory Safety. ACM Trans. Embed. Comput. Syst. 18, 6, Article 122 (Nov. 2019), 27 pages.
https://doi.org/10.1145/3362064
[74] Chris Lattner and Vikram Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transfor-
mation. In Proceedings of the International Symposium on Code Generation and Optimization (Palo Alto, California)
(CGO ’04). IEEE Computer Society, Washington, DC, USA.
[75] Bozhen Liu and Jeff Huang. 2018. D4: Fast Concurrency Debugging with Parallel Differential Analysis. SIGPLAN Not.
53, 4 (Jun 2018), 359–373. https://doi.org/10.1145/3296979.3192390
[76] Bozhen Liu, Jeff Huang, and Lawrence Rauchwerger. 2019. Rethinking Incremental and Parallel Pointer Analysis.
ACM Trans. Program. Lang. Syst. 41, 1, Article 6 (March 2019), 31 pages. https://doi.org/10.1145/3293606
[77] LLVM-Developer-Community. 2017. LLVM GitHub Repository. Retrieved August 26, 2024 from https://github.com/
llvm/llvm-project/commit/b323f4f173710c60bcc76628d8155e476023c5b5
[78] LLVM-Developer-Community. 2024. LLVM GitHub Repository. Retrieved September 2, 2024 from https://github.com/
llvm/llvm-project
[79] Yi Lu, Lei Shang, Xinwei Xie, and Jingling Xue. 2013. An Incremental Points-to Analysis with CFL-Reachability. In
Compiler Construction, Ranjit Jhala and Koen De Bosschere (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg,
61–81.
[80] Magnus Madsen and Ond𝜗rej Lhoták. 2020. Fixpoints for the masses: programming with first-class Datalog constraints.
Proc. ACM Program. Lang. 4, OOPSLA, Article 125 (Nov. 2020), 28 pages. https://doi.org/10.1145/3428193
[81] Magnus Madsen, Ming-Ho Yee, and Ond𝜗rej Lhoták. 2016. From Datalog to Flix: a Declarative Language for Fixed
Points on Lattices. In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and
Implementation (Santa Barbara, CA, USA) (PLDI ’16). Association for Computing Machinery, New York, NY, USA,
194–208. https://doi.org/10.1145/2908080.2908096
[82] T.J. Marlowe and B.G. Ryder. 1991. Hybrid Incremental Alias Algorithms. In Proceedings of the Twenty-Fourth Annual
Hawaii International Conference on System Sciences, Vol. ii. 428–437 vol.2. https://doi.org/10.1109/HICSS.1991.184005
[83] Thomas J. Marlowe and Barbara G. Ryder. 1989. An Efficient Hybrid Algorithm for Incremental Data Flow Analysis.
In Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (San Francisco,
California, USA) (POPL ’90). Association for Computing Machinery, New York, NY, USA, 184–196. https://doi.org/10.
1145/96709.96728
[84] Stephen P. Masticola and Barbara G. Ryder. 1993. Non-Concurrency Analysis. SIGPLAN Not. 28, 7 (Jul 1993), 129–138.
https://doi.org/10.1145/173284.155346
[85] J. Micallef and G.E. Kaiser. 1993. Support Algorithms for Incremental Attribute Evaluation of Asynchronous Subtree

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:29

Replacements. IEEE Transactions on Software Engineering 19, 3 (1993), 231–252. https://doi.org/10.1109/32.221136

[86] Prasoon Mishra and V. Krishna Nandivada. 2024. COWS for High Performance: Cost Aware Work Stealing for
Irregular Parallel Loop. ACM Transactions on Architecture and Code Optimization 21, 1, Article 12 (Jan 2024), 26 pages.
https://doi.org/10.1145/3633331
[87] Steven S. Muchnick. 1998. Advanced Compiler Design and Implementation. Morgan Kaufmann Publishers Inc., San
Francisco, CA, USA.
[88] Steven S. Muchnick and Neil D. Jones. 1981. Program Flow Analysis: Theory and Application. Prentice Hall Professional
Technical Reference.
[89] Nomair A. Naeem, Ond𝜗rej Lhoták, and Jonathan Rodriguez. 2010. Practical Extensions to the IFDS Algorithm. In
Compiler Construction, Rajiv Gupta (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 124–144.
[90] Lawton Nichols, Mehmet Emre, and Ben Hardekopf. 2019. Fixpoint Reuse for Incremental JavaScript Analysis. In
Proceedings of the 8th ACM SIGPLAN International Workshop on State Of the Art in Program Analysis (Phoenix, AZ, USA)
(SOAP 2019). Association for Computing Machinery, New York, NY, USA, 2–7. https://doi.org/10.1145/3315568.3329964
[91] Emma Nilsson-Nyman, Görel Hedin, Eva Magnusson, and Torbjörn Ekman. 2009. Declarative Intraprocedural Flow
Analysis of Java Source Code. Electronic Notes in Theoretical Computer Science 238, 5 (2009), 155–171. Proceedings of
the 8th Workshop on Language Descriptions, Tools and Applications (LDTA 2008).
[92] Aman Nougrahiya and V. Krishna Nandivada. 2019. IMOP : IIT Madras OpenMP compiler framework. https://github.
com/amannougrahiya/imop-compiler
[93] Aman Nougrahiya and V. Krishna Nandivada. 2024. Homeostasis: Design and Implementation of a Self-Stabilizing
Compiler. ACM Transactions on Programming Languages and Systems 46, 2, Article 6 (May 2024), 58 pages. https:
//doi.org/10.1145/3649308
[94] Oracle. 1999. HotSpot. https://github.com/openjdk-mirror/jdk7u-hotspot
[95] Rohan Padhye and Uday P. Khedker. 2013. Interprocedural Data Flow Analysis in Soot using Value Contexts. In
Proceedings of the 2nd ACM SIGPLAN International Workshop on State Of the Art in Java Program Analysis (Seattle,
Washington) (SOAP ’13). Association for Computing Machinery, New York, NY, USA, 31–36. https://doi.org/10.1145/
2487568.2487569
[96] Komal Pathade and Uday Khedker. 2023. Computing Maximum Fixed Point Solutions over Feasible Paths in Data
Flow Analyses. Science of Computer Programming 228 (2023), 102944. https://doi.org/10.1016/j.scico.2023.102944
[97] L. L. Pollock and M. L. Soffa. 1989. An Incremental Version of Iterative Data Flow Analysis. IEEE Transactions on
Software Engineering 15, 12 (1989), 1537–1549.
[98] Germán Puebla and Manuel Hermenegildo. 1996. Optimized Algorithms for Incremental Analysis of Logic Programs.
In Static Analysis, Radhia Cousot and David A. Schmidt (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 270–284.
[99] Daniel Quinlan, Chunhua Liao, Thomas Panas, Robb Matzke, Markus Schordan, Rich Vuduc, and Qing Yi. 2013.
ROSE User Manual: A Tool for Building Source-to-Source Translators. Technical Report. Lawrence Livermore National
Laboratory.
[100] G. Ramalingam and Thomas Reps. 1994. An Incremental Algorithm for Maintaining the Dominator Tree of a
Reducible Flowgraph. In Proceedings of the 21st ACM SIGPLAN-SIGACT Symposium on Principles of Programming
Languages (Portland, Oregon, USA) (POPL ’94). Association for Computing Machinery, New York, NY, USA, 287–296.
https://doi.org/10.1145/174675.177905
[101] Thomas Reps. 1982. Optimal-Time Incremental Semantic Analysis for Syntax-Directed Editors. In Proceedings of the
9th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Albuquerque, New Mexico) (POPL
’82). Association for Computing Machinery, New York, NY, USA, 169–176. https://doi.org/10.1145/582153.582172
[102] Thomas Reps. 1988. Incremental Evaluation for Attribute Grammars with Unrestricted Movement between Tree
Modifications. Acta Informatica 25, 2 (1988), 155–178. https://doi.org/10.1007/BF00263583
[103] Thomas Reps. 1994. Solving Demand Versions of Interprocedural Analysis Problems. In Compiler Construction,
Peter A. Fritzson (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 389–403.
[104] Thomas Reps, Susan Horwitz, and Mooly Sagiv. 1995. Precise Interprocedural Dataflow Analysis via Graph Reach-
ability. In Proceedings of the 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages
(San Francisco, California, USA) (POPL ’95). Association for Computing Machinery, New York, NY, USA, 49–61.
https://doi.org/10.1145/199448.199462
[105] Thomas Reps, Tim Teitelbaum, and Alan Demers. 1983. Incremental Context-Dependent Analysis for Language-Based
Editors. ACM Trans. Program. Lang. Syst. 5, 3 (July 1983), 449–477. https://doi.org/10.1145/2166.357218
[106] Sara Royuela, Roger Ferrer, Diego Caballero, and Xavier Martorell. 2015. Compiler Analysis for OpenMP Tasks
Correctness. In Proceedings of the 12th ACM International Conference on Computing Frontiers (Ischia, Italy) (CF ’15).
Association for Computing Machinery, New York, NY, USA, Article 7, 8 pages. https://doi.org/10.1145/2742854.2742882
[107] Radu Rugina and Martin C. Rinard. 2003. Pointer Analysis for Structured Parallel Programs. ACM Trans. Program.
Lang. Syst. 25, 1 (Jan 2003), 70–116. https://doi.org/10.1145/596980.596982

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:30 Nougrahiya and Nandivada

[108] B.G. Ryder, T.J. Marlowe, and M.C. Paull. 1988. Conditions for Incremental Iteration: Examples and Counterexamples.
Science of Computer Programming 11, 1 (1988), 1–15.
[109] Barbara G. Ryder. 1983. Incremental Data Flow Analysis. In Proceedings of the 10th ACM SIGACT-SIGPLAN Symposium
on Principles of Programming Languages (Austin, Texas) (POPL ’83). Association for Computing Machinery, New York,
NY, USA, 167–176. https://doi.org/10.1145/567067.567084
[110] Barbara G. Ryder and Marvin C. Paull. 1986. Elimination Algorithms for Data Flow Analysis. ACM Comput. Surv. 18,
3 (Sep 1986), 277–316. https://doi.org/10.1145/27632.27649
[111] Barbara G. Ryder and Marvin C. Paull. 1988. Incremental Data-Flow Analysis Algorithms. ACM Trans. Program. Lang.
Syst. 10, 1 (Jan 1988), 1–50. https://doi.org/10.1145/42192.42193
[112] Mooly Sagiv, Thomas Reps, and Susan Horwitz. 1996. Precise Interprocedural Dataflow Analysis with Applications
to Constant Propagation. Theoretical Computer Science 167, 1 (1996), 131–170. https://doi.org/10.1016/0304-3975(96)
00072-2
[113] Diptikalyan Saha and C. R. Ramakrishnan. 2005. Incremental and Demand-Driven Points-to Analysis Using Logic
Programming. In Proceedings of the 7th ACM SIGPLAN International Conference on Principles and Practice of Declarative
Programming (Lisbon, Portugal) (PPDP ’05). Association for Computing Machinery, New York, NY, USA, 117–128.
https://doi.org/10.1145/1069774.1069785
[114] Diptikalyan Saha and C. R. Ramakrishnan. 2005. Symbolic Support Graph: A Space Efficient Data Structure for
Incremental Tabled Evaluation. In Logic Programming, Maurizio Gabbrielli and Gopal Gupta (Eds.). Springer Berlin
Heidelberg, Berlin, Heidelberg, 235–249.
[115] Diptikalyan Saha and C. R. Ramakrishnan. 2006. A Local Algorithm for Incremental Evaluation of Tabled Logic
Programs. In Logic Programming, Sandro Etalle and Mirosław Truszczyński (Eds.). Springer Berlin Heidelberg, Berlin,
Heidelberg, 56–71.
[116] João Saraiva, Doaitse Swierstra, and Matthijs Kuiper. 2000. Functional Incremental Attribute Evaluation. In Compiler
Construction, David A. Watt (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 279–294.
[117] Shigehisa Satoh, Kazuhiro Kusano, and Mitsuhisa Sato. 2001. Compiler Optimization Techniques for OpenMP
Programs. Scientific Programming 9, 2-3 (2001), 131–142.
[118] Bernhard Scholz, Herbert Jordan, Pavle Subotić, and Till Westmann. 2016. On Fast Large-Scale Program Analysis
in Datalog. In Proceedings of the 25th International Conference on Compiler Construction (Barcelona, Spain) (CC ’16).
Association for Computing Machinery, New York, NY, USA, 196–206. https://doi.org/10.1145/2892208.2892226
[119] Seager, M. 2008. The ASC Sequoia Programming Model. (8 2008). https://doi.org/10.2172/945684
[120] Helmut Seidl, Julian Erhard, and Ralf Vogler. 2020. Incremental Abstract Interpretation. Springer International
Publishing, Cham, 132–148. https://doi.org/10.1007/978-3-030-41103-9_5
[121] Lei Shang, Yi Lu, and Jingling Xue. 2012. Fast and Precise Points-to Analysis with Incremental CFL-Reachability
Summarisation: Preliminary Experience. In 2012 Proceedings of the 27th IEEE/ACM International Conference on
Automated Software Engineering. 270–273. https://doi.org/10.1145/2351676.2351720
[122] Shikha Singh, Sergey Madaminov, Michael A. Bender, Michael Ferdman, Ryan Johnson, Benjamin Moseley, Hung Ngo,
Dung Nguyen, Soeren Olesen, Kurt Stirewalt, and Geoffrey Washburn. 2020. A Scheduling Approach to Incremental
Maintenance of Datalog Programs. In 2020 IEEE International Parallel and Distributed Processing Symposium (IPDPS).
864–873. https://doi.org/10.1109/IPDPS47924.2020.00093
[123] Jeff Smits and Eelco Visser. 2017. FlowSpec: Declarative Dataflow Analysis Specification. In Proceedings of the 10th
ACM SIGPLAN International Conference on Software Language Engineering (Vancouver, BC, Canada) (SLE 2017).
Association for Computing Machinery, New York, NY, USA, 221–231. https://doi.org/10.1145/3136014.3136029
[124] Soot-Developer-Community. 2024. Soot GitHub Repository. Retrieved September 2, 2024 from https://github.com/soot-
oss/soot
[125] Vugranam C. Sreedhar, Guang R. Gao, and Yong-Fong Lee. 1996. A New Framework for Exhaustive and Incremental
Data Flow Analysis Using DJ Graphs. In Proceedings of the ACM SIGPLAN 1996 Conference on Programming Language
Design and Implementation (Philadelphia, Pennsylvania, USA) (PLDI ’96). Association for Computing Machinery, New
York, NY, USA, 278–290. https://doi.org/10.1145/231379.231434
[126] Vugranam C. Sreedhar, Guang R. Gao, and Yong-Fong Lee. 1997. Incremental Computation of Dominator Trees. ACM
Trans. Program. Lang. Syst. 19, 2 (Mar 1997), 239–252. https://doi.org/10.1145/244795.244799
[127] Richard M. Stallman and GCC-Developer-Community. 2009. Using The GNU Compiler Collection: A GNU Manual For
GCC Version 4.3.3. CreateSpace, Paramount, CA.
[128] Benno Stein, Bor-Yuh Evan Chang, and Manu Sridharan. 2021. Demanded Abstract Interpretation. In Proceedings
of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation (Virtual,
Canada) (PLDI 2021). Association for Computing Machinery, New York, NY, USA, 282–295. https://doi.org/10.1145/
3453483.3454044
[129] Zewen Sun, Duanchen Xu, Yiyu Zhang, Yun Qi, Yueyang Wang, Zhiqiang Zuo, Zhaokang Wang, Yue Li, Xuandong Li,

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:31

Qingda Lu, Wenwen Peng, and Shengjian Guo. 2023. BigDataflow: A Distributed Interprocedural Dataflow Analysis
Framework. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the
Foundations of Software Engineering (San Francisco, CA, USA) (ESEC/FSE 2023). Association for Computing Machinery,
New York, NY, USA, 1431–1443. https://doi.org/10.1145/3611643.3616348
[130] Tamás Szabó. 2023. Incrementalizing Production CodeQL Analyses. In Proceedings of the 31st ACM Joint European
Software Engineering Conference and Symposium on the Foundations of Software Engineering (San Francisco, CA, USA)
(ESEC/FSE 2023). Association for Computing Machinery, New York, NY, USA, 1716–1726. https://doi.org/10.1145/
3611643.3613860
[131] Tamás Szabó, Gábor Bergmann, Sebastian Erdweg, and Markus Voelter. 2018. Incrementalizing Lattice-Based
Program Analyses in Datalog. Proc. ACM Program. Lang. 2, OOPSLA, Article 139 (oct 2018), 29 pages. https:
//doi.org/10.1145/3276509
[132] Tamás Szabó, Sebastian Erdweg, and Gábor Bergmann. 2021. Incremental Whole-Program Analysis in Datalog with
Lattices. In Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and
Implementation (Virtual, Canada) (PLDI 2021). Association for Computing Machinery, New York, NY, USA, 1–15.
https://doi.org/10.1145/3453483.3454026
[133] Tamás Szabó, Sebastian Erdweg, and Markus Voelter. 2016. IncA: A DSL for the Definition of Incremental Program
Analyses. In Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering (Singapore,
Singapore) (ASE 2016). Association for Computing Machinery, New York, NY, USA, 320–331. https://doi.org/10.1145/
2970276.2970298
[134] Robert Tarjan. 1973. Testing Flow Graph Reducibility. In Proceedings of the Fifth Annual ACM Symposium on Theory
of Computing (Austin, Texas, USA) (STOC ’73). Association for Computing Machinery, New York, NY, USA, 96–107.
https://doi.org/10.1145/800125.804040
[135] J. D. Ullman. 1972. A Fast Algorithm for the Elimination of Common Subexpressions. In 13th Annual Symposium on
Switching and Automata Theory (swat 1972). 161–176. https://doi.org/10.1109/SWAT.1972.1
[136] Raja Vallée-Rai, Phong Co, Etienne Gagnon, Laurie Hendren, Patrick Lam, and Vijay Sundaresan. 2010. Soot: A
Java Bytecode Optimization Framework. In CASCON First Decade High Impact Papers (Toronto, Ontario, Canada)
(CASCON ’10). IBM Corp., USA, 214–224. https://doi.org/10.1145/1925805.1925818
[137] Jens Van der Plas, Quentin Stiévenart, and Coen De Roover. 2023. Result Invalidation for Incremental Modular
Analyses. In Verification, Model Checking, and Abstract Interpretation, Cezara Dragoi, Michael Emmi, and Jingbo Wang
(Eds.). Springer Nature Switzerland, Cham, 296–319.
[138] Jens Van der Plas, Quentin Stiévenart, Noah Van Es, and Coen De Roover. 2020. Incremental Flow Analysis through
Computational Dependency Reification. In 2020 IEEE 20th International Working Conference on Source Code Analysis
and Manipulation (SCAM). 25–36. https://doi.org/10.1109/SCAM51674.2020.00008
[139] Rob F Van der Wijngaart and Parkson Wong. 2002. NAS parallel benchmarks version 3.0. Technical Report. NAS
technical report, NAS-02-007.
[140] Jyothi Krishna Viswakaran Sreelatha and Shankar Balachandran. 2016. Compiler Enhanced Scheduling for OpenMP
for Heterogeneous Multiprocessors. In Workshop on Energy Efficiency with Heterogeneous Computing (EEHCO ’16).
ACM, Prague, Czech Republic.
[141] Jyothi Krishna Viswakaran Sreelatha, Shankar Balachandran, and Rupesh Nasre. 2018. CHOAMP: Cost Based
Hardware Optimization for Asymmetric Multicore Processors. IEEE Trans. Multi-Scale Computing Systems 4, 2 (2018),
163–176.
[142] Jyothi Krishna Viswakaran Sreelatha and Rupesh Nasre. 2018. Optimizing Graph Algorithms in Asymmetric Multicore
Processors. IEEE Trans. on CAD of Integrated Circuits and Systems 37, 11 (2018), 2673–2684.
[143] Frédéric Vivien and Martin Rinard. 2001. Incrementalized Pointer and Escape Analysis. SIGPLAN Not. 36, 5 (May
2001), 35–46. https://doi.org/10.1145/381694.378804
[144] J. A. Walz and G. F. Johnson. 1988. Incremental Evaluation for a General Class of Circular Attribute Grammars. In
Proceedings of the ACM SIGPLAN 1988 Conference on Programming Language Design and Implementation (Atlanta,
Georgia, USA) (PLDI ’88). Association for Computing Machinery, New York, NY, USA, 209–221. https://doi.org/10.
1145/53990.54011
[145] Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, Xiaoheng Xie, and Xiangyu Zhang. 2024. When Dataflow
Analysis Meets Large Language Models. CoRR abs/2402.10754 (2024). https://doi.org/10.48550/ARXIV.2402.10754
arXiv:2402.10754
[146] Dashing Yeh. 1983. On Incremental Evaluation of Ordered Attribute Grammars. BIT Numerical Mathematics 23, 3
(1983), 308–320. https://doi.org/10.1007/BF01934460
[147] D. Yeh and U. Kastens. 1988. Improvements of an Incremental Evaluation Algorithm for Ordered Attribute Grammars.
SIGPLAN Not. 23, 12 (Dec 1988), 45–50. https://doi.org/10.1145/57669.57672
[148] Jyh-shiarn Yur, Barbara G. Ryder, and William A. Landi. 1999. An Incremental Flow- and Context-Sensitive Pointer

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:32 Nougrahiya and Nandivada

Aliasing Analysis. In Proceedings of the 21st International Conference on Software Engineering (Los Angeles, California,
USA) (ICSE ’99). Association for Computing Machinery, New York, NY, USA, 442–451. https://doi.org/10.1145/302405.
302676
[149] Jyh-Shiarn Yur, Barbara G. Ryder, William A. Landi, and Phil Stocks. 1997. Incremental Analysis of Side Effects for C
Software System. In Proceedings of the 19th International Conference on Software Engineering (Boston, Massachusetts,
USA) (ICSE ’97). Association for Computing Machinery, New York, NY, USA, 422–432. https://doi.org/10.1145/253228.
253369
[150] Frank Kenneth Zadeck. 1984. Incremental Data Flow Analysis in a Structured Program Editor. In Proceedings of the
1984 SIGPLAN Symposium on Compiler Construction (Montreal, Canada) (SIGPLAN ’84). Association for Computing
Machinery, New York, NY, USA, 132–143. https://doi.org/10.1145/502874.502888
[151] Sheng Zhan and Jeff Huang. 2016. ECHO: Instantaneous in Situ Race Detection in the IDE. In Proceedings of the 2016
24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (Seattle, WA, USA) (FSE 2016).
Association for Computing Machinery, New York, NY, USA, 775–786. https://doi.org/10.1145/2950290.2950332
[152] Yuan Zhang and Evelyn Duesterwald. 2007. Barrier Matching for Programs with Textually Unaligned Barriers.
In Proceedings of the 12th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (San Jose,
California, USA) (PPoPP ’07). Association for Computing Machinery, New York, NY, USA, 194–204. https://doi.org/
10.1145/1229428.1229472
[153] Yuan Zhang, Evelyn Duesterwald, and Guang R. Gao. 2008. Concurrency Analysis for Shared Memory Programs with
Textually Unaligned Barriers. Springer-Verlag, Berlin, Heidelberg, Chapter Languages and Compilers for Parallel
Computing, 95–109. https://doi.org/10.1007/978-3-540-85261-2_7
[154] David Zhao, Pavle Subotic, Mukund Raghothaman, and Bernhard Scholz. 2021. Towards Elastic Incrementalization
for Datalog. In 23rd International Symposium on Principles and Practice of Declarative Programming (Tallinn, Estonia)
(PPDP 2021). Association for Computing Machinery, New York, NY, USA, Article 20, 16 pages. https://doi.org/10.
1145/3479394.3479415

A FORMAL DESCRIPTION AND CORRECTNESS OF INCIDFA

In Section A.1, we provide detailed proofs of correctness for precision and soundness guarantees of
IncIDFA. Then, for sake of completeness, we also present the formal description of the traditional
iterative dataflow analysis, CompIDFA in Section A.2.

A.1 Correctness Proofs for IncIDFA

Consider a dataflow analysis A = (L, F , M). Let A = (𝑃, 𝜗𝑒 ) be an analysis instance of A, where
𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived upon applying a sequence of one or more transformations on
some program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let seeds = seeds(𝑃old, 𝑃) represent the set of seed nodes for
program transformations from 𝑃old to 𝑃. Let 𝑑 old be the MFP solution of some analysis instance
Aold = (𝑃old, Mold, 𝜗𝑒 ) for A. Given the analysis instance A, and the incremental-analysis instance
I = (A, seeds, 𝑑 old ), in this section we prove the equivalence of CompIDFA and IncIDFA by showing
that the fixed-point solutions obtained upon application of evalComp on the initial CompIDFA-state
of A, and evalInc on the initial IncIDFA-state of I, are the same.

Consistency and Safety.

In this section, we formally describe two fundamental ideas, namely consistency and safety, which
form the basis for our correctness arguments for IncIDFA.

Definition A.1 (Consistent node). Consider a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) for some analysis
instance A = (𝑃, 𝜗𝑒 ), or for some incremental-analysis instance I = (A, seeds, 𝑑 old ). For any
node 𝑛 ∈ 𝑁 , we term 𝑛 as a consistent node with respect to 𝑑𝑖 , denoted as consistent(𝑛, 𝑑𝑖 ), if and

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:33

only if the following holds:


𝜗𝑒, if 𝑛 = 𝑛 0
.


IN𝑖 (𝑛) = OUT (𝑝), otherwise
𝑝 ∈pred𝑃 (𝑛) 𝑖


and
OUT𝑖 (𝑛) = 𝜏𝑛 (IN𝑖 (𝑛)), where 𝜏𝑛 = M(𝑛).
Note that when a node is consistent with respect to a dataflow state, its IN and OUT dataflow facts
will not change upon recalculation. In contrast, if the OUT dataflow fact of a node changes upon its
recalculation, then the successors of the node may become inconsistent with respect to the updated
dataflow state.
Definition A.2 (Consistent SCC). Consider a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) for some analysis
instance A = (𝑃, 𝜗𝑒 ), or for some incremental-analysis instance I = (A, seeds, 𝑑 old ). Given
scc𝑃 (𝑘), the SCC with index 𝑘 in the topological sort order of SDG𝑃 , we term scc𝑃 (𝑘) as a
consistent SCC with respect to 𝑑𝑖 , denoted as consistentSCC(𝑘, 𝑑𝑖 ), if and only if the following
holds: ∀𝑛 ∈ sccNodes𝑃 (𝑘), consistent(𝑛, 𝑑𝑖 ).
Theorem A.3 (Fixed-point via consistency). A dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) is a fixed-point
solution for the analysis instance A = (𝑃, 𝜗𝑒 ), as well as for all the incremental-analysis instances of
the form I = (A, ∗, ∗), if and only if the following holds: ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ).

Proof. Follows directly from Definitions 4.4 and A.1. □

Definition A.4 (Safe node). Consider a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) for some analysis in-
stance A = (𝑃, 𝜗𝑒 ), or for some incremental-analysis instance I = (A, seeds, 𝑑 old ). Let 𝑑 mfp =
(INmfp, OUTmfp ) be the MFP solution of A. For any node 𝑛 ∈ 𝑁 , we term 𝑛 as a safe node with
respect to 𝑑𝑖 , denoted as safe(𝑛, 𝑑𝑖 ), if and only if the following holds:
INmfp (𝑛) ⊑ IN𝑖 (𝑛), and OUTmfp (𝑛) ⊑ OUT𝑖 (𝑛)
Note that for a given node 𝑛, and a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) of analysis instance A (or I),
if IN𝑖 (n) = ⊤ and OUT𝑖 (𝑛) = ⊤, then safe(𝑛, 𝑑𝑖 ) trivially holds. Similarly, if 𝑑𝑖 is the MFP solution
of A (or I), then ∀𝑛 ∈ 𝑁 , safe(𝑛, 𝑑𝑖 ) trivially holds.
Definition A.5 (Safe SCC). Consider a dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) for some analysis in-
stance A = (𝑃, 𝜗𝑒 ), or for some incremental-analysis instance I = (A, seeds, 𝑑 old ). Let 𝑑 mfp =
(INmfp, OUTmfp ) be the MFP solution of A. Given scc𝑃 (𝑘), the SCC with index 𝑘 in the topological
sort order of SDG𝑃 , we term scc𝑃 (𝑘) as a safe SCC with respect to 𝑑𝑖 , denoted as safeSCC(𝑘, 𝑑𝑖 ),
if and only if the following holds: ∀𝑛 ∈ sccNodes𝑃 (𝑘), safe(𝑛, 𝑑𝑖 ).
Theorem A.6 (Maximum fixed-point as consistency and safety). A dataflow state 𝑑𝑖 =
(IN𝑖 , OUT𝑖 ) is the maximum fixed-point solution for the analysis instance A, as well as for all the
incremental-analysis instances of the form I = (A, ∗, ∗), if and only if the following holds: ∀𝑛 ∈
𝑁 , consistent(𝑛, 𝑑𝑖 ) ∧ safe(𝑛, 𝑑𝑖 ).

Proof. There are two parts to this proof.

Part A: Consistency and safety imply MFP: Assume ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ) ∧ safe(𝑛, 𝑑𝑖 ).
Since ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ), from Theorem A.3 we conclude that 𝑑𝑖 is a fixed-point solution
of A (or I). Let 𝑑 mfp = (INmfp, OUTmfp ) be the MFP solution for A (or I). Since 𝑑𝑖 is a fixed-point
solution, from Definition 4.5 of the MFP solution, we know that ∀𝑛 ∈ 𝑁 :
IN𝑖 (𝑛) ⊑ INmfp (𝑛) ∧ OUT𝑖 (𝑛) ⊑ OUTmfp (𝑛) (1)

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:34 Nougrahiya and Nandivada

Since ∀𝑛 ∈ 𝑁 , safe(𝑛, 𝑑𝑖 ), from Definition A.4 of safe nodes we conclude that ∀𝑛 ∈ 𝑁 :

INmfp (𝑛) ⊑ IN𝑖 (𝑛) ∧ OUTmfp (𝑛) ⊑ OUT𝑖 (𝑛) (2)
From (1) and (2), we have, IN𝑖 = INmfp ∧ OUT𝑖 = OUTmfp , that is, 𝑑𝑖 = 𝑑 mfp , the MFP solution.
Part B: MFP implies consistency and safety: Assume that 𝑑𝑖 is the MFP solution for A (or I).
Since an MFP solution is also a fixed-point solution, we conclude from Definition 4.4 that ∀𝑛 ∈ 𝑁 :

𝜗𝑒, if 𝑛 = 𝑛 0
.


IN𝑖 (𝑛) = OUT (𝑝), otherwise
𝑝 ∈pred𝑃 (𝑛) 𝑖


and
OUT𝑖 (𝑛) = 𝜏𝑛 (IN𝑖 (𝑛)), where 𝜏𝑛 = M(𝑛)
Hence, by Definition A.1, ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ) holds. Similarly, since 𝑑𝑖 is the MFP solution of
A (or I), we conclude from Definition A.4 that ∀𝑛 ∈ 𝑁 , safe(𝑛, 𝑑𝑖 ) holds. Hence proved. □
Corollary A.7 (Maximum fixed-point as consistency and safety per SCC). Consider an
analysis instance A = (𝑃, 𝜗𝑒 ), or some incremental-analysis instance of the form I = (A, ∗, ∗).
Let |SDG𝑃 | denote the number of SCCs in SDG𝑃 . A dataflow state 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) is the maximum
fixed-point solution for A (or I), if and only if the following holds:
|SDG𝑃 | −1
∀ (consistentSCC(𝑘, 𝑑𝑖 ) ∧ safeSCC(𝑘, 𝑑𝑖 ))
𝑘=0

Proof. Follows directly from Theorem A.6 and Definitions A.2 and A.5. □
Lemma A.8 (Consistency and safety with processNode). Consider an invocation of the helper
function processNode, with arguments 𝑑𝑖 = (IN𝑖 , OUT𝑖 ), 𝑛, and 𝑄 to obtain the resulting dataflow
state 𝑑 𝑗 = (IN 𝑗 , OUT 𝑗 ). We note that
• if 𝑄 = pred𝑃 (𝑛), then consistent(𝑛, 𝑑 𝑗 ) holds, and
• if ∀𝑞 ∈ 𝑄, safe(𝑞, 𝑑𝑖 ) is true, then safe(𝑛, 𝑑 𝑗 ) holds.
Proof. The first part of the lemma, about consistency of 𝑛 with respect to 𝑑 𝑗 when 𝑄 is the
complete set of predecessors of 𝑛, follows directly from Definition A.1, and Fig. 5. We now prove
the second part of the lemma.
Let 𝑑 mfp = (INmfp, OUTmfp ) be the MFP solution.
INmfp (𝑛) = ⊓ OUTmfp (𝑞) (from Definition 4.5)
𝑞 ∈𝑄
⊑ ⊓ OUT𝑖 (𝑞) (from Definition A.4)
𝑞 ∈𝑄
= IN 𝑗 (𝑛) (from Fig. 5)
Hence, INmfp (𝑛) ⊑ IN 𝑗 (𝑛). From Definition A.4 of safe nodes, we conclude that safe(𝑛, 𝑑 𝑗 ) holds.
□
Theorem A.9 (Consistency and safety with CompIDFA). Consider a dataflow analysis A =
(L, F , M), and its analysis instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). Let |SDG𝑃 | denote the
number of SCCs in SDG𝑃 . If Sc𝑖 = <|SDG𝑃 | − 1, ∅, 𝑑𝑖 > is the resulting CompIDFA-state from the fixed-
point application of evalComp on initStateComp (A), then, ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ) ∧ safe(𝑛, 𝑑𝑖 ).
Proof. From Theorem A.31, 𝑑𝑖 is the MFP solution for A. Hence, from Theorem A.6, we conclude
that ∀𝑛 ∈ 𝑁 , consistent(𝑛, 𝑑𝑖 ) ∧ safe(𝑛, 𝑑𝑖 ). □

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:35

Corollary A.10 (Consistency and safety per SCC with CompIDFA). Consider a dataflow
analysis A = (L, F , M), and its analysis instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). Let |SDG𝑃 |
denote the number of SCCs in SDG𝑃 . If Sc𝑖 = <|SDG𝑃 | − 1, ∅, 𝑑𝑖 > is the resulting CompIDFA-state from
the fixed-point application of evalComp on initStateComp (A), then,
|SDG𝑃 | −1
∀ (consistentSCC(𝑘, 𝑑𝑖 ) ∧ safeSCC(𝑘, 𝑑𝑖 ))
𝑘=0

Proof. Follows directly from Theorem A.31 and Corollary A.7. □

Consistency and safety upon program transformations.

Consider a dataflow analysis A = (L, F , M), and its analysis instance A = (𝑃, 𝜗𝑒 ), where
𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived upon applying a sequence of one or more transformations on some
program 𝑃 old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let Aold = (𝑃old, Mold, 𝜗𝑒 ) be the analysis instance of A for 𝑃 old ,
and 𝑑 old = (INold, OUTold ) be the MFP solution of Aold . Let seeds = seeds(𝑃old, 𝑃) represent the set
of seed nodes from 𝑃 old to 𝑃.
Lemma A.11 (Unaffected SCCs). Consider an SCC, say scc𝑃 (𝑘), from the SDG of 𝑃, such that
sccNodes𝑃 (𝑘) does not contain any seed nodes. Let 𝑑𝑖 = (IN𝑖 , OUT𝑖 ) be a dataflow state for A, such
that, ∀𝑛 ∈ sccNodes𝑃 (𝑘), IN𝑖 (𝑛) = INold (𝑛) ∧ OUT𝑖 (𝑛) = OUTold (𝑛). Let 𝑄 be the set of all those
nodes that are predecessors of the nodes in sccEntryNodes𝑃 (𝑘), but do not belong to sccNodes𝑃 (𝑘).
If each element of 𝑄 is consistent and safe with respect to 𝑑𝑖 , and if the OUT dataflow facts for all these
elements match their values in 𝑑 old , then all nodes in sccNodes𝑃 (𝑘) too are consistent and safe in 𝑑𝑖 .

Proof. (Sketch.) Consider that we reset and recompute the dataflow facts of all nodes in the SCC.
Since the incoming dataflow facts to the SCC are consistent and safe, the recomputed fixed-point
dataflow facts for the nodes in the SCC too will be consistent and safe. We now argue that the
fixed-point results of recomputation will match the results stored in 𝑑 old .
Since sccNodes𝑃 (𝑘) does not contain any seed nodes, we note that the set of predecessors for
all nodes in the SCC, including the entry-nodes, remain unchanged. Consequently, the dataflow
equations for none of the nodes change. Since the incoming dataflow facts (OUT of the nodes in set
𝑄, and the set 𝑄 itself) do not change, we note that recalculation of the dataflow facts for all nodes
in the SCC will yield the same result as stored in 𝑑 old .
We leave a formal proof for this lemma as an exercise for the reader. □

Informally, in the context of program transformations, this lemma states that if there are no seed
nodes in an SCC, if the incoming dataflow facts to the SCC have not changed from their fixed-point
values since before the transformations, and if the incoming dataflow facts are consistent and safe
with respect to some dataflow state after the transformation, then the dataflow facts for the nodes
in the SCC too are consistent and safe with respect to that dataflow state. This implies that such an
SCC need not be processed to obtain the MFP solution after the transformations.
Consistency and safety for SCCs unreachable from seed nodes.
Consider a dataflow analysis A, and its analysis instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 )
has been derived upon applying a sequence of one or more transformations on some program
𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let seeds = seeds(𝑃old, 𝑃) represent the set of seed nodes for program
transformations from 𝑃old to 𝑃. Let 𝑑 old be the MFP solution of some analysis instance Aold =
(𝑃old, Mold, 𝜗𝑒 ) for A.
Lemma A.12 (Unreachable SCCs). For an incremental-analysis instance I = (A, seeds, 𝑑 old ),
assume Simfp = eval∞ Inc (initStateIncIDFA (I)), is the result of the fixed-point application of evalInc . Let
𝑑 mfp be the dataflow state in Simfp . In the topological sort order of SDG𝑃 , let 𝑘 be the minimum index

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:36 Nougrahiya and Nandivada

of any SCC that contains a seed node. We note that the SCCs that are unreachable from the seed nodes
are consistent and safe with respect to 𝑑 mfp . Formally,
𝑙 <𝑘
𝑘 = min (sccID𝑃 (𝑠)) ⇒ ∀ , consistentSCC(𝑙, 𝑑 mfp ) ∧ safeSCC(𝑙, 𝑑 mfp ) (3)
∀𝑠 ∈seeds 𝑙=0

Proof. Let Siinit be the initial IncIDFA-state of instance I, and let 𝑑 init be the dataflow state in
Siinit . For all SCCs that are unreachable from the seed node, it directly follows from Lemma A.11
(using strong induction on the index of SCCs), that the SCCs are consistent and safe with respect
to 𝑑 init .
From Definition 4.11, we note that the first SCC to be processed by evalInc is that with index 𝑘.
From Rule [PhC-FP], and definition of the method firstNodeWithLeastSCCId, we note that the
SCCs are processed in the increasing order of their indices. Hence, this ensures that the dataflow
facts in 𝑑 mfp (the fixed-point state) for program nodes in SCCs that are unreachable from the seed
nodes, remain unchanged from their values in 𝑑 init . Since these SCCs are consistent and safe with
respect to 𝑑 init , their safety and consistency hold for 𝑑 mfp as well. □

Reachability in evalInc .
In the rest of the formalism, N0 denotes the set of all natural numbers and zero. For any 𝑝 ∈ N0 , we
use evalInc 𝑝 (Si𝑖 ) to denote 𝑝 applications of the function evalInc on some IncIDFA-state Si𝑖 . Note
that evalInc 0 (Si𝑖 ) = Si𝑖 . As before, the fixed-point application of evalInc is denoted by evalInc ∞ (Si𝑖 ).
Definition A.13 (Reachable IncIDFA-state). Consider an incremental-analysis instance, I, as
discussed above. An IncIDFA-state, Si𝑖 ∈ S𝐼 is considered as a reachable IncIDFA-state,
denoted by reachable(Si𝑖 , I), if and only if there exists an interpretation of firstNode and
firstNodeWithLeastSCCId, such that, ∃𝑝 ∈ N0, Si𝑖 = evalInc 𝑝 (initStateIncIDFA (I)).
Informally, in the context of an incremental-analysis instance I, an IncIDFA-state is consid-
ered reachable if and only if it can be obtained upon applying the evalInc function on the initial
IncIDFA-state for I zero or more times.
Definition A.14 (SCC-init state). Consider an SCC at index 𝑘 in the topological sort order of the
SDG𝑃 . We term an IncIDFA-state as the initial state of the SCC, denoted by SCC-init(𝑘), if it is of
the form <𝑘, sccEntryNodes𝑃 (𝑘), 𝑑𝑖 , ∅, ∅, ∅, O𝑘 , PhA, ∗>, where:
𝑑𝑖 = (IN𝑖 , OUT𝑖 )
∀𝑥 ∈ sccExitNodes𝑃 (𝑘), O𝑘 (𝑥) = OUT𝑖 (𝑥)
Informally, if the SCC-init state for SCC at index 𝑘 in the topological sort order of the SDG𝑃 is
reachable upon zero or more applications of evalInc on the initial IncIDFA-state of an incremental-
analysis instance I, then it implies that the SCC is processed by the IncIDFA algorithm. Note that
the initial IncIDFA-state is an SCC-init state.
Termination of processing of an SCC by evalInc .
We now argue the termination of processing of evalInc when it reaches a state which is SCC-init
state for some SCC.
Definition A.15 (SCC-fixed-point states). Consider an SCC at some index 𝑘 in the topological sort
order of the SDG𝑃 . We define three types of fixed-point IncIDFA-states for the SCC, as follows:
• PhA-fixed-point states, which are of the form <𝑘, ∅, ∗, ∗, ∗, ∗, O𝑘 , PhA, ∗>,
• PhB-fixed-point states, which are of the form <𝑘, ∅, ∗, ∗, ∗, ∅, O𝑘 , PhB, ∗>, and
• PhC-fixed-point states, which are of the form <𝑘, ∅, ∗, ∅, ∅, ∅, O𝑘 , PhC, ∗>.
If a IncIDFA-state, say Si𝑖 is PhA-fixed-point, PhB-fixed-point, or PhC-fixed-point for some SCC
with index 𝑘, then we denote these facts as isSCC-PhA-FP(Si𝑖 , 𝑘), isSCC-PhB-FP(Si𝑖 , 𝑘), or isSCC-
PhC-FP(Si𝑖 , 𝑘), respectively.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:37

Informally, these IncIDFA-states denote the termination of the corresponding phases while pro-
cessing any SCC.
Lemma A.16 (Termination of PhA). Consider an incremental-analysis instance, I, as discussed
above. If the initial state of an SCC is reachable from the initial IncIDFA-state for I, then some
PhA-fixed-point state is reachable as well for the SCC. Formally,
reachable(SCC-init(𝑘), I) ⇒ ∃Si𝑖 ∈ S𝐼 , isSCC-PhA-FP(Si𝑖 , 𝑘) ∧ reachable(Si𝑖 , I)
Proof. At each step of application of evalInc , starting with the state SCC-init(𝑘), either of the
two rules [PhA-Mark] or [PhA-Proc] from Fig. 4 will be applicable, until a PhA-fixed-point state is
reached. Each application of either of these rules non-deterministically removes one node from the
worklist and processes it. The processed node is added to the set S𝑘 . In both these rules, we note
that if a node is present in the set S𝑘 , then it is not added back to the worklist. This implies that a
node can get added at most once to the worklist. Given the finite number of nodes in sccNodes𝑃 (𝑘),
the worklist will be empty after at most |sccNodes𝑃 (𝑘)| applications of the evalInc function, leading
to an IncIDFA-state which is a PhA-fixed-point state. Hence proved. □
Lemma A.17 (Termination of PhB). Consider an incremental-analysis instance, I, as discussed
above. If the initial state of an SCC is reachable from the initial IncIDFA-state for I, then some
PhB-fixed-point state is reachable as well for the SCC. Formally,
reachable(SCC-init(𝑘), I) ⇒ ∃Si𝑖 ∈ S𝐼 , isSCC-PhB-FP(Si𝑖 , 𝑘) ∧ reachable(Si𝑖 , I)
Proof. From Lemma A.16, we note that an IncIDFA-state which is a PhA-fixed-point state is
reachable for I. In the next application of evalInc , rule [PhA-FP] from Fig. 4 is applicable, resulting
in some IncIDFA-state of the form <𝑘, ∗, ∗, ∗, ∗, ∅, ∗, PhB, ∗>. Starting with that state, the argument
for reachability of a PhB-fixed-point state is similar as that used in Lemma A.16, relying on the
rule [PhB-Proc] from Fig. 6. □
Lemma A.18 (Termination of PhC). Consider an incremental-analysis instance, I, as discussed
above. If the initial state of an SCC is reachable from the initial IncIDFA-state for I, then some
PhC-fixed-point state is reachable as well for the SCC. Formally,
reachable(SCC-init(𝑘), I) ⇒ ∃Si𝑖 ∈ S𝐼 , isSCC-PhC-FP(Si𝑖 , 𝑘) ∧ reachable(Si𝑖 , I)
Proof. From Lemma A.17, we note that an IncIDFA-state which is a PhB-fixed-point state is
reachable for I. In the next application of evalInc , rule [PhB-FP] from Fig. 6 is applicable, resulting
in an IncIDFA-state of the form <𝑘,𝑊𝑘 , ∗, ∅, ∅, ∅, ∗, PhC, ∗>. If 𝑊𝑘 is empty, then a PhC-fixed-point
state has been reached. Otherwise, rule [PhC-Proc] from Fig. 7 is applicable. Note that a node may
get added to the worklist at most as many times as is the height of the lattice [87, 88]. Hence the
worklist will get empty after a finite number of applications of the rule [PhC-Proc], resulting in a
PhC-fixed-point state. Hence proved. □
From Lemmas A.16, A.17, and A.18, we infer that if an SCC is processed by evalInc , then the
processing eventually terminates. We now prove that upon termination of processing of an SCC,
the SCC is rendered consistent and safe with the current dataflow state.
Consistency and safety of SCCs processed by evalInc .
Now, we gradually discuss the guarantees of consistency and safety for nodes in the SCCs that are
processed by evalInc .
Lemma A.19 (PhB leads to consistent or underapproximated nodes). Consider an incremental-
analysis instance I = (A, seeds, 𝑑 old ), as discussed above. Assume that SCC-init(𝑘), the initial
state for SCC at index 𝑘 in the topological sort order of SDG𝑃 , is a reachable IncIDFA-state for the

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:38 Nougrahiya and Nandivada

incremental-analysis instance I. Let Si𝑖 = <𝑘, ∅, 𝑑𝑖 , S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 > be the PhB-fixed-point

state that is reached upon zero or more applications of evalInc on SCC-init(𝑘). We note that in Si𝑖 ,
∀𝑛 ∈ sccNodes𝑃 (𝑘), consistent(𝑛, 𝑑𝑖 ) ∨ 𝑛 ∈ U𝑘 .

Proof. Consider a node, say 𝑛, in the set sccNodes𝑃 (𝑘). Two cases arise on the basis of whether
node 𝑛 was present in the intra-SCC worklist, 𝑊𝑘 , in any IncIDFA-state between SCC-init(𝑘) and
Si𝑖 :
Case A: Node 𝑛 was present in 𝑊𝑘 in some IncIDFA-state. Three sub-cases arise on the basis of
the evaluation rule that was used for processing 𝑛 in PhA or PhB:
Case A.i: [PhA-Mark] In this case, all predecessors of node 𝑛 are present in the set M𝑘 . As
per Rules [PhA-Mark] and [PhA-Proc], a node gets added to the set M𝑘 only if its OUT dataflow
fact does not change upon its processing. Hence, the OUT of none of the predecessors of node 𝑛
changed. Since 𝑛 is not a seed node, its set of predecessors (pred𝑃 (𝑛)) too remains unchanged.
Hence, from Definition A.1, consistent(𝑛, 𝑑𝑖 ) holds.
Case A.ii: [PhA-Proc] Assume that 𝑑 ′ is the dataflow state in the IncIDFA-state obtained
upon application of this rule. In this rule, method processNode gets invoked on 𝑛. If the set 𝑄 𝑝
is same as pred𝑃 (𝑛), then consistent(𝑛, 𝑑 ′ ) holds, as per Lemma A.8. Otherwise, as per this
rule, node 𝑛 gets added to the set U𝑘 ′ of the resulting IncIDFA-state.
Case A.iii: [PhB-Proc] This case is similar to Case A.iii above.
Case B: Node 𝑛 was never added to 𝑊𝑘 . Clearly, node 𝑛 is not a seed node. In this case, for each
predecessor of node 𝑛 in the same SCC, say 𝑝 ∈ sameSccPred𝑃 (𝑛), there are two possibilities:
(i) Node 𝑝 was not processed in any IncIDFA-state between SCC-init(𝑘) and Si𝑖 . (ii) Node
𝑝 was processed as per Rule [PhB-Proc], but its processing resulted in no change in its
OUT dataflow fact. In both these cases, since the OUT dataflow fact does not change for any
predecessor of 𝑛, and since 𝑛 is clearly not a seed node, from Definition A.1, consistent(𝑛, 𝑑𝑖 )
holds.
Hence proved. □

Lemma A.20 (Set M𝑘 is a subset of S𝑘 ). Consider an incremental-analysis instance I, as discussed

above. Assume that SCC-init(𝑘) is a reachable IncIDFA-state for I. Let Si𝑎 be the PhA-fixed-point
state that is reached upon zero or more applications of evalInc on SCC-init(𝑘). We note that for all
IncIDFA-state Si𝑖 = <𝑘, ∅, 𝑑𝑖 , S𝑘 , U𝑘 , M𝑘 , O𝑘 , PhA,𝑊𝑔 >, that lie between SCC-init(𝑘) and Si𝑎 (both
inclusive), the following holds: M𝑘 ⊆ S𝑘 .

Proof. Elements in set M𝑘 are added only in case of Rules [PhA-Mark] and [PhA-Proc]. In both
these cases, the element gets added to set S𝑘 as well. Hence, M𝑘 ⊆ S𝑘 . □

Lemma A.21 (Set S𝑘 is safe). Consider an incremental-analysis instance I, as discussed above.

Assume that SCC-init(𝑘) is a reachable IncIDFA-state for I. Further, assume that all SCCs with
index less than 𝑘 are consistent and safe. Let Si𝑏 be the PhB-fixed-point state that is reached
upon zero or more applications of evalInc on SCC-init(𝑘). We note that for all IncIDFA-state
Si𝑖 = <𝑘, ∅, 𝑑𝑖 , S𝑘 , U𝑘 , M𝑘 , O𝑘 , ∗,𝑊𝑔 >, that lie between SCC-init(𝑘) and Si𝑏 (both inclusive), the fol-
lowing holds: ∀𝑛 ∈ S𝑘 , safe(𝑛, 𝑑𝑖 ).
𝑝
Proof. Consider an integer 𝑝 ∈ N0 , such that evalInc (SCC-init(𝑘)) = Si𝑏 . We prove that the
lemma holds by using induction on the value of 𝑝.
Base case: Assume 𝑝 = 0. In this case, the IncIDFA-state obtained is SCC-init(𝑘). In this state,
the set S𝑘 is empty. Hence the lemma trivially holds.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:39

Inductive hypothesis: Consider an IncIDFA-state, say Si𝑞 , such that Si𝑞 =

𝑞
<𝑘, ∅, 𝑑𝑞 , S𝑞 , U𝑞 , M𝑞 , O𝑘 , PhB,𝑊𝑔 > = evalInc (SCC-init(𝑘)). For all nodes 𝑛 ∈ S𝑞 , safe(𝑛, 𝑑𝑞 )
holds.
Inductive step: Consider an IncIDFA-state, say Si𝑞+1 , such that Si𝑞+1 =
(𝑞+1)
<𝑘, ∅, 𝑑𝑞+1, S𝑞+1, U𝑞+1, M𝑞+1, O𝑘 , PhB,𝑊𝑔 > = evalInc (SCC-init(𝑘)). Now, we need to
prove that for all nodes 𝑛 ∈ S𝑞+1, safe(𝑛, 𝑑𝑞+1 ) holds. Four cases arise, on the basis of the
evaluation rule that was used to take this step:
[PhA-Mark] Let 𝑛 be the node returned by the firstNode method upon application of this
rule. In this case, all predecessors of node 𝑛 belong to the set M𝑘 , which implies that they
are also present in the set S𝑞 (from Lemma A.20). Furthermore, the OUT dataflow facts did
not change for any of these predecessors. Since the dataflow fact of 𝑛 are not recalculated, it
is clear that they are safe with respect to the current dataflow state, 𝑑𝑞+1 . Since 𝑛 is the only
new element in S𝑞+1 , it proves that all elements of S𝑞+1 are safe with respect to 𝑑𝑞+1 .
[PhA-Proc] Let 𝑛 be the node returned by the firstNode method upon application of this
rule. The set 𝑄 𝑝 passed to the method processNode contains two parts: (i) predecessors of 𝑛
that belong to previous SCCs (which are given to be safe), and (ii) predecessors of 𝑛 that
belong to this SCC and are present in S𝑞 (that is, are safe). Since all elements of 𝑄 𝑝 are safe
with respect to 𝑑𝑞 , from Lemma A.8, we note that node 𝑛 is safe with respect to 𝑑𝑞+1 .
[PhA-FP] In this rule, no changes are made to S𝑞 to obtain S𝑞+1 . Hence, all nodes in S𝑞+1 are
safe with respect to 𝑑𝑞+1 .
[PhB-Proc] The reasoning for this case is similar to that for Rule [PhA-Proc].
Hence proved.
□

Lemma A.22 (PhB leads to safe nodes). Consider an incremental-analysis instance I, as discussed
above. Assume that SCC-init(𝑘) is a reachable IncIDFA-state for I. Further, assume that all SCCs
with index less than 𝑘 are consistent and safe. Let Si𝑏 = <𝑘, ∅, 𝑑𝑏 , S𝑘 , U𝑘 , ∅, O𝑘 , PhB,𝑊𝑔 > be the PhB-
fixed-point state that is reached upon zero or more applications of evalInc on SCC-init(𝑘). We note
that ∀𝑛 ∈ sccNodes𝑃 (𝑘), safe(𝑛, 𝑑𝑏 ).

Proof. Consider a node, say 𝑛, in the set sccNodes𝑃 (𝑘). Two cases arise on the basis of whether
node 𝑛 was present in the intra-SCC worklist, 𝑊𝑘 , in any IncIDFA-state between SCC-init(𝑘) and
Si𝑏 :
Case A: Node 𝑛 was present in 𝑊𝑘 in some state. The evaluation rules that could be used for
processing 𝑛 in PhA or PhB are Rules [PhA-Mark], [PhA-Proc], or [PhB-Proc]. In all these
rules, node 𝑛 gets added to the set S𝑘 . From Lemma A.21, we conclude, safe(𝑛, 𝑑𝑏 ).
Case B: Node 𝑛 was never added to 𝑊𝑘 . Clearly, node 𝑛 is not a seed node. In this case, for each
predecessor of node 𝑛 in the same SCC, say 𝑝 ∈ sameSccPred𝑃 (𝑛), there are two possibilities:
(i) Node 𝑝 was not processed in any IncIDFA-state between SCC-init(𝑘) and Si𝑏 . (ii) Node
𝑝 was processed as per Rule [PhB-Proc], but its processing resulted in no change in its
OUT dataflow fact. In both these cases, since the OUT dataflow fact does not change for any
predecessor of 𝑛, and since 𝑛 is clearly not a seed node, from Definition A.4, safe(𝑛, 𝑑𝑏 ) holds.
□

Lemma A.23 (PhC leads to consistent and safe nodes). Consider an incremental-analysis
instance I, as discussed above. Assume that SCC-init(𝑘) is a reachable IncIDFA-state for
I. Further, assume that all SCCs with index less than 𝑘 are consistent and safe. Let Si𝑐 =
<𝑘, ∅, 𝑑𝑐 , ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 > be the PhC-fixed-point state that is reached upon zero or more applica-

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:40 Nougrahiya and Nandivada

tions on the PhB-fixed-point state, say Si𝑏 , for the SCC. We note that ∀𝑛 ∈ sccNodes𝑃 (𝑘), safe(𝑛, 𝑑𝑐 )∧
consistent(𝑛, 𝑑𝑐 ).
Proof. Note that in the IncIDFA-state Si𝑏 , all the nodes are safe, as per Lemma A.22. For all
IncIDFA-states between Si𝑏 and Si𝑐 , the only rule applicable is Rule [PhC-Proc]. Consider any such
IncIDFA-state, say Si𝑖 . Let 𝑛 be the node that was returned by method firstNode. Note that since the
helper method processNode is invoked with only the safe predecessors of 𝑛 (which, in this case, are
all the predecessors of 𝑛), from Lemma A.8, node 𝑛 is safe in evalInc (Si𝑖 ). Hence, for all IncIDFA-state
between Si𝑏 and Si𝑐 (both inclusive), we conclude that ∀𝑛 ∈ sccNodes𝑃 (𝑘), safe(𝑛, 𝑑𝑐 ).
From Lemma A.19, in IncIDFA-state Si𝑏 , we note that all nodes in sccNodes𝑃 (𝑘) are either
consistent, or are present in the set U𝑏 . From Rule [PhB-FP], note that the intra-SCC worklist, 𝑊𝑘 ,
for PhC is populated with U𝑏 . Hence, in IncIDFA-state Si𝑏 , all nodes in sccNodes𝑃 (𝑘) are present
in 𝑊𝑘 , or are consistent. It is easy to see that this property holds for each IncIDFA-state between
Si𝑏 and Si𝑐 : At each step, only Rule [PhC-Proc] is applicable. With this rule, the node, say 𝑛, that is
taken from the worklist, is processed using processNode with the complete set of predecessors of 𝑛
(that is, pred𝑃 (𝑛)). Hence, from Lemma A.8, we know that node 𝑛 is consistent in the resulting
IncIDFA-state. If the OUT dataflow facts of node 𝑛 changes, its successors may become inconsistent
with the resulting IncIDFA-state, and hence are added back to 𝑊𝑘 . Hence, we conclude that since
𝑊𝑘 is empty in the IncIDFA-stateSi𝑐 , ∀𝑛 ∈ sccNodes𝑃 (𝑘), consistent(𝑛, 𝑑𝑐 ).
Hence proved. □
Corollary A.24 (evalInc leads to consistent and safe SCC). Consider an incremental-
analysis instance I, as discussed above. Assume that SCC-init(𝑘) is a reachable IncIDFA-state
for I. Further, assume that all SCCs with index less than 𝑘 are consistent and safe. Let Si𝑐 =
<𝑘, ∅, 𝑑𝑐 , ∅, ∅, ∅, O𝑘 , PhC,𝑊𝑔 > be the PhC-fixed-point state that is reached upon zero or more ap-
plications on the PhB-fixed-point state, say Si𝑏 , for the SCC. We note that safeSCC(𝑘, 𝑑𝑖 ) ∧
consistentSCC(𝑘, 𝑑𝑖 ) hold.
Proof. Follows directly from Lemma A.23 and Definitions A.5 and A.2. □

Consistency and safety of SCCs unprocessed by evalInc .

Lemma A.25. Consider an incremental-analysis instance I, as discussed above. Assume Simfp =

eval∞
Inc (initStateIncIDFA (I)), is the result of the fixed-point application of evalInc . Let 𝑑 mfp be the
dataflow state in Simfp . In the topological sort order of SDG𝑃 , let 𝑘 be the minimum index of any SCC
that contains a seed node. Assume an SCC, with index 𝑘, such that SCC-init(𝑘) is not reachable from
I. We note that safeSCC(𝑘, 𝑑 mfp ) and consistentSCC(𝑘, 𝑑 mfp ) hold.
Proof. Since SCC with index 𝑘 has not been processed by evalInc , it is clear that it does not
contain any seed nodes. Furthermore, there must not have been any applications of Rule [PhC-FP],
where the OUT of any of the predecessors of any entry node of scc𝑃 (𝑘) changed (else scc𝑃 (𝑘) would
have been processed). Consequently, from Lemma A.11, we conclude that safeSCC(𝑘, 𝑑 mfp ) and
consistentSCC(𝑘, 𝑑 mfp ) hold. □

Consistency and safety of all SCCs with evalInc .

Theorem A.26. Consider a dataflow analysis A, and its analysis instance A = (𝑃, 𝜗𝑒 ), where
𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived upon applying a sequence of one or more transformations on some
program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let Aold = (𝑃old, Mold, 𝜗𝑒 ) be an analysis instance of A for 𝑃old , and
let 𝑑 old be its MFP solution. Let seeds = seeds(𝑃old, 𝑃) represent the set of seed nodes for program

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:41

transformations from 𝑃old to 𝑃. Given the incremental-analysis instance I = (A, seeds, 𝑑 old ), let
Simfp = eval∞Inc (initStateIncIDFA (I)) be the result of fixed-point application of the evalInc for I. Let
𝑑 mfp be the dataflow state in Simfp . The following holds:
𝑘<|SDG𝑃 |
∀ , consistentSCC(𝑘, 𝑑 mfp ) ∧ safeSCC(𝑘, 𝑑 mfp )
𝑘=0

Proof. In the topological sort order of SDG𝑃 , let 𝑚 be the minimum index of any SCC that contains
a seed node. For all SCCs with index less than 𝑚, the proof follows directly from Lemma A.12. For
other SCCs, we prove the theorem by strong induction on their indices.
Base case: For scc𝑃 (𝑚). The initial IncIDFA-state, as per Definition 4.11, is clearly SCC-init(𝑚).
From Lemma A.18, we note that the PhC-fixed-point of scc𝑃 (𝑚) is reachable. From Corol-
lary A.24, we conclude that consistentSCC(𝑚, 𝑑 mfp ) and safeSCC(𝑚, 𝑑 mfp ) hold.
Induction hypothesis: Assume that ∀𝑙, 𝑚 < 𝑙 < (𝑘 − 1) consistentSCC(𝑙, 𝑑 mfp ) and
safeSCC(𝑙, 𝑑 mfp ) holds.
Inductive step: To prove that consistentSCC(𝑘, 𝑑 mfp ) and safeSCC(𝑘, 𝑑 mfp ) holds. On the basis
of whether scc𝑃 (𝑘) has been processed by evalInc , two cases arise:
Case A: scc𝑃 (𝑘) has been processed by evalInc . In this case, the proof follows directly from
Corollary A.24.
Case B: scc𝑃 (𝑘) has not been processed by evalInc . In this case, the proof follows directly
from Lemma A.25.
Hence proved.
□

Corollary A.27. Consider a dataflow analysis A, and its analysis instance A = (𝑃, 𝜗𝑒 ), where
𝑃 = (𝑁 , 𝐸, 𝑛 0 ) has been derived upon applying a sequence of one or more transformations on some
program 𝑃old = (𝑁 old, 𝐸 old, 𝑛 0 ). Let Aold = (𝑃old, Mold, 𝜗𝑒 ) be an analysis instance of A for 𝑃old , and
let 𝑑 old be its MFP solution. Let seeds = seeds(𝑃old, 𝑃) represent the set of seed nodes for program
transformations from 𝑃old to 𝑃. Given the incremental-analysis instance I = (A, seeds, 𝑑 old ), let
Simfp = eval∞ Inc (initStateIncIDFA (I)) be the result of fixed-point application of the evalInc for I. Let
𝑑 mfp be the dataflow state in Simfp . The following holds: 𝑑 mfp = mfp(A).

Proof. Follows directly from Theorem A.26, and Corollary A.7. □

A.2 Formal Model for CompIDFA

In this section, we formalize the traditional exhaustive iterative dataflow analysis algorithm
CompIDFA.
Definition A.28 (CompIDFA-state). In the context of CompIDFA, at any point during the application
of the algorithm, we define the analysis state, termed CompIDFA-state, as a 3-tuple of the form
Sc𝑖 = <𝑘,𝑊𝑘 , 𝑑>, where:
• 𝑘 is the index of the current SCC being processed by the analysis, in the topological sort order
(0-indexed) of SDG𝑃 , the SDG of the program being analyzed.
• 𝑊𝑘 denotes an intra-SCC worklist, containing those nodes of the current SCC for which the
dataflow facts may require recalculation.
• 𝑑 represents the current dataflow state.
We denote the set of all CompIDFA-states by S𝐶 .

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:42 Nougrahiya and Nandivada

Sc = <𝑘,𝑊𝑘 , 𝑑> 𝑊𝑘 ≠ <> 𝑛 = firstNode(𝑊𝑘 )

𝑑 = (IN, OUT) 𝑑 ′ = (IN′, OUT′ ) = processNode(𝑑, 𝑛, pred𝑃 (𝑛))
(
′ (𝑊𝑘 \ {𝑛}) ∪ sameSccSucc𝑃 (𝑛), if OUT′ (𝑛) ≠ OUT(𝑛)
𝑊𝑘 =
(𝑊𝑘 \ {𝑛}), otherwise
[Comp-Proc]
evalComp (Sc) ⇒ <𝑘,𝑊𝑘′, 𝑑 ′ >

Sc = <𝑘, <>, 𝑑> 𝑘 ≤ (|SDG𝑃 | − 2)

[Comp-SCC-FP]
evalComp (Sc) ⇒ <𝑘 + 1, sccNodes𝑃 (𝑘 + 1), 𝑑>

Sc = <𝑘, <>, 𝑑> 𝑘 = (|SDG𝑃 | − 1)

[Comp-Global-FP]
evalComp (Sc) ⇒ Sc

Fig. 15. Evaluation rules for the evalComp function.

Definition A.29 (Initial CompIDFA-state). Consider a dataflow analysis A = (L, F , M), and its
analysis instance A = (𝑃, 𝜗𝑒 ), where 𝑃 = (𝑁 , 𝐸, 𝑛 0 ). In the context of analysis instance A, we
define the initial CompIDFA-state as initStateComp (A) = <0, sccNodes𝑃 (0), 𝑑 init >, where
𝑑 init = (INinit, OUTinit )
(
𝜗𝑒 , if 𝑛 = 𝑛 0
∀𝑛 ∈ 𝑁 , INinit (𝑛) =
⊤, otherwise
∀𝑛 ∈ 𝑁 , OUTinit (𝑛) = ⊤
Definition A.30 (evalComp function). We formally represent the CompIDFA algorithm using a func-
tion evalComp : S𝐶 → S𝐶 , which takes the current CompIDFA-state, and performs one step of the
CompIDFA algorithm to generate the next CompIDFA-state.
For a given analysis instance A, the application of CompIDFA algorithm can be seen as a fixed-
point application of the evalComp function, denoted by evalComp ∞ , on the initial CompIDFA-state,
initStateComp (A).
Fig. 15 defines the evaluation rules for the evalComp function, discussed next.
[Comp-Proc] When the intra-SCC worklist, 𝑊𝑘 , is not empty in the current CompIDFA-state, a
node is removed (non-deterministically, using the operation firstNode) from the worklist, and
its dataflow facts are recalculated by invoking the helper method processNode. If recalculation
resulted in a change in the OUT dataflow fact for 𝑛, then those successors of 𝑛 that belong
to the same SCC as that of 𝑛 are added to the intra-SCC worklist, 𝑊𝑘 . Note that the order
in which nodes are taken from an intra-SCC worklist does not change the final fixed-point
solution obtained for that SCC.
[Comp-SCC-FP] When the intra-SCC worklist, 𝑊𝑘 , is empty in the current CompIDFA-state, then
the state represents a local fixed-point for the nodes in the current SCC. If the current SCC
is not the last SCC in the topological sort order of SDG𝑃 , then the index information for the
SCC being processed is incremented by one. Further, all nodes that belong to the immediately
succeeding SCC in the topological sort, are added to the intra-SCC worklist.
[Comp-Global-FP] If the intra-SCC worklist, 𝑊𝑘 , is empty in the current CompIDFA-state, and if
the current SCC is the last SCC in the topological sort order of SDG𝑃 , then a global fixed-point
has been reached for the application of evalComp .

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:43

Theorem A.31 (Correctness of evalComp ). For a given analysis instance A = (𝑃, 𝜗𝑒 ), a fixed-point
application of the evalComp function on the initial CompIDFA-state for A, converges to a CompIDFA-state
that contains the maximum fixed-point solution for A. Formally,
evalComp ∞ (initStateComp (A)) = <|SDG𝑃 | − 1, <>, 𝑑 mfp > ⇔ 𝑑 mfp = mfp(A)
Proof. The proofs for convergence and correctness of standard iterative dataflow analysis algo-
rithm, employed by the function evalComp , are standard [87, 88], and hence omitted. □

B GENERIC INCREMENTAL IDFA

In this section, we present IncIDFA, a generic, incremental, flow-sensitive, interprocedural dataflow
algorithm, which can be used to derive an incremental version of any arbitrary monotone iterative
dataflow analysis. IncIDFA can be instantiated to write any IDFA-based analysis (for example,
reaching-definitions analysis, liveness analysis, and so on), including those analyses that are non-
distributive (such as points-to analysis and constant-propagation analysis). IncIDFA does not
require the dataflow analysis writer to provide any details that are specific to incrementalization of
the analysis.

B.1 Design of IncIDFA

Given a program 𝑃, for any monotone dataflow analysis 𝑋 , the traditional generic iterative dataflow
analysis algorithm (CompIDFA) computes the dataflow solution (the IN and OUT maps) of 𝑋 for 𝑃, by
taking as input (i) the lattice L of 𝑋 , and (ii) the flow-function map F (that returns the flow function
F𝑛 for every program node 𝑛) for 𝑋 . Without loss of generality, in this manuscript, we assume
that each program is represented as a graph (for example, control-flow graph, or super-graph; see
Section 2).
Say 𝑃𝑖 be a program under compilation whose dataflow solution (IN𝑖 and OUT𝑖 maps) has been
computed for a monotone dataflow analysis 𝑋 . Consider a modified program 𝑃 𝑗 , obtained by
performing a series of compiler transformations on 𝑃𝑖 . For each such analysis 𝑋 , the goal of our
proposed algorithm is to compute the modified dataflow solution of 𝑋 for 𝑃 𝑗 by incrementally
updating the prior computed dataflow solution (IN𝑖 and OUT𝑖 ). Such incremental updates would
require, in addition to other arguments, the information about the overall differences from 𝑃𝑖 to 𝑃 𝑗 .
For simplicity, one can assume that these differences are given in terms of sets of (i) nodes added
(addedNodes), (ii) nodes removed (removedNodes), (iii) edges added (addedEdges), and (iv) edges
removed (removedEdges) – collectively called as the change-set.
We take these requirements into consideration and propose a generic incremental iterative dataflow
analysis algorithm, termed IncIDFA. For obtaining the dataflow solution of 𝑋 for 𝑃 𝑗 , in addition
to the arguments that are required by CompIDFA (namely, L, F and 𝑃 𝑗 ), IncIDFA needs only the
following additional arguments: the old dataflow solution (IN and OUT for 𝑃𝑖 ) and the change-set
(from 𝑃𝑖 to 𝑃 𝑗 ).

B.2 IncIDFA Algorithm

In this section, we describe our proposed worklist-based algorithm (IncIDFA) that works on the
SCC decomposition of the program’s super-graph (see Section 2); hereafter, we call this graph as the
SCC-graph. Without loss of generality, we discuss this algorithm for forward IDFAs; the algorithm
for backward IDFAs can be derived similarly. The key intuition of this algorithm is derived from
Proposal 3 (Optimized Init-Restart-SCC) discussed in Section 3.4.
The IncIDFA algorithm is shown in Fig. 16. It starts by invoking the function obtainSeedNodes
(see Section 2) to process the change-set (chSet) to obtain the set of seed program-nodes in the
current program 𝑃. The ordered-set globalWL is kept sorted by the SCC ids of the program-nodes,

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:44 Nougrahiya and Nandivada

1 Function IncIDFA(L, F, 𝑃 , chSet, IN, OUT) /* Modifies IN and OUT */

2 // L: lattice for the analysis; F: flow function map for the analysis
3 // 𝑃 : modified program as per which the analysis results have to be updated
4 // chSet: change-set denoting the differences from 𝑃 old to 𝑃
5 // IN and OUT: dataflow solution of the analysis for some program 𝑃 old
6 OrderedSet globalWL = obtainSeedNodes(chSet, 𝑃 );
7 while globalWL ≠ ∅ do processOneSCC(L, F, IN, OUT, globalWL) ;
8 Function processOneSCC(L, F, IN, OUT, globalWL) /* Modifies IN, OUT, and globalWL */
9 sccID = globalWL.peekFirst().getSCCId(); // SCC ID of the first node in globalWL
10 /* Step I: Extract all seed nodes belonging to this SCC. */
11 currSCCSeeds = globalWL.removeAllWithId(sccID);
12 /* Step II: Store the stale OUT information of exit nodes of this SCC. */
13 foreach 𝑛 ∈ getExits(sccID) do oldOUT(𝑛) = OUT(𝑛).clone();
14 /* Step III: (Initialization-step): under-approximation for the current SCC. */
15 safeNodes = ∅; underApprox = ∅;
16 if currSCCSeeds ⊈ getEntries(sccID) then
17 underApproximate(L, F, IN, OUT, safeNodes, underApprox, currSCCSeeds, getEntries(sccID), true);
18 underApproximate(L, F, IN, OUT, safeNodes, underApprox, currSCCSeeds, currSCCSeeds.clone(), false);
19 /* Step IV: (Stabilization-step): get MFP solution for the current SCC. */
20 stabilize(L, F, 𝑃 , IN, OUT, underApprox);
21 /* Step V: Add required successors from other SCCs to globalWL */
22 foreach 𝑛 ∈ getExits(sccID) do
23 if oldOUT(𝑛) ! = OUT(𝑛) then
Ð
24 globalWL = globalWL (succ(n) \ getSCCNodes(sccID));

Fig. 16. Algorithm for incremental update of flow-facts, for a forward analysis on serial programs.

to ensure that the affected SCCs are processed as per the topological sort order of the SCCs in the
SCC-graph. Besides the standard operations like peekFirst, the ordered-set globalWL supports
an additional method removeAllWithId, which given an SCC id as an argument, removes (and
returns) the set of all the elements with the given SCC id.
The method IncIDFA processes one SCC at a time by invoking the method processOneSCC,
which in turn processes each SCC in five steps, in order to implement the initialization-step and
stabilization-step discussed in Proposal 3:
Step I: For the SCC being processed, we first extract (in currSCCSeeds) all those program-nodes
from globalWL that belong to this SCC. These program-nodes are the directly impacted nodes as
a result of either (i) any program-changes performed within this SCC, or (ii) any changes in the
incoming flowmaps from one or more of the predecessor SCCs.
Step II: Note that during stabilization of dataflow solution within this SCC, the OUT flowmaps of
any of the program-nodes may temporarily be under-approximated before they stabilize back to
their fixed-point values. In many cases, we observe that the initial values (before the initialization-
step) of the flowmaps for certain program-nodes match the fixed-point values at the end of the
stabilization-step. When such program-nodes are also the exit nodes of the SCC, the standard
IDFA approach may unnecessarily mark their successor program-nodes (from successor SCCs) to
be processed, when the OUT flowmaps of the exit nodes change temporarily. This may result in
redundant processing of successor SCCs. To avoid this issue, when we process a program-node,
we do not add the inter-SCC successor program-nodes to the worklist. Instead, in Step II, we
take a snapshot of the OUT flowmaps of all the exit nodes (obtained through getExits, Line 13),
and compare it with the final fixed-point values (in Step V), to decide if any inter-SCC successor
program-nodes need to be added to globalWL.
Step III: (Initialization-step) We define a program-node to be safe (as discussed in Proposal 3), if (i)
the program-node is not reachable from any seed node, or (ii) both its IN and OUT flowmaps are safe

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:45

1 Function underApproximate(L, F, IN, OUT, safeNodes, underApprox, currSCCSeeds, intraSCCWL,

unconditionallyAdd) /* Modifies IN, OUT, safeNodes, underApprox, and intraSCCWL */
2 // safeNodes: set of nodes that have been processed during the initialization-step
3 // underApprox: set of nodes for which at least one predecessor was ignored during the initialization-step
4 // unconditionallyAdd: true, when the successors need to be added unconditionally to the worklist
5 unchangedOUTNodes = ∅;
6 while intraSCCWL is not empty do
7 𝑛 = intraSCCWL.removeFirst();
8 if 𝑛 ∈ safeNodes then continue;
9 boolean hasOUTChanged = false; Ð
10 if pred(n) ⊆ unchangedOUTNodes then unchangedOUTNodes = {n};
11 else
12 safePreds = {𝑝 : 𝑝 ∈ pred(n) && (𝑝.getSCCId() ≠ 𝑛.getSCCId() | | 𝑝 ∈ safeNodes) };
13 if safePreds ! = pred(𝑛) then underApprox ∪ = {𝑛} ;
14 hasOUTChanged = processNode(𝑛, L, F, IN, OUT, safePreds); Ð
15 if hasOUTChanged == false then unchangedOUTNodes = {n};
Ð
16 safeNodes = {𝑛}; Ð
17 skipSuccs = safeNodes currSCCSeeds ; Ð
18 if unconditionallyAdd | | hasOUTChanged then intraSCCWL = (intraSCCSucc(𝑛) \ skipSuccs);

19 Function stabilize(L, F, IN, OUT, intraSCCWL) /* Modifies IN, OUT, and intraSCCWL */
20 while intraSCCWL is not empty do
21 𝑛 = intraSCCWL.removeFirst();
22 boolean hasOUTChanged = processNode(𝑛,
Ð L, F, IN, OUT, pred(𝑛));
23 if hasOUTChanged then intraSCCWL = intraSCCSucc(𝑛);

Fig. 17. Definitions for underApproximate and stabilize methods used while processing an SCC.
1 Function processNode(𝑛, L, F, IN, OUT, safePreds): boolean /* Modifies IN and OUT */
2 // Returns true if the OUT flowmap of 𝑛 has changed
3 // safePreds: set of predecessors whose OUT is a safe
. initial estimate
4 if safePreds == ∅ then IN(𝑛) = ⊤; else IN(𝑛) = 𝑝 ∈safePreds OUT(𝑝 );
5 OUT(𝑛) = F𝑛 (IN(𝑛));
6 if OUT(𝑛) has changed then return true;
7 else return false;

Fig. 18. Algorithm to recalculate IN and OUT of a program node.

(i.e., are safe-initial-estimates). We define the IN flowmap of a node as safe, if (i) the flowmap maps
all domain-elements to ⊤, or (ii) it has been computed using the OUT flowmaps of its predecessors
that are safe. Similarly, we define the OUT flowmaps of a node as safe, if (i) the flowmap maps all
domain-elements to ⊤, or (ii) it has been computed using the safe IN flowmap of its node. From
Section 3, recall that if all the program-nodes of an SCC are safe, then no ghost-mappings can
be present in the fixed-point solution. In this step, we implement the initialization-step (and its
optimizations discussed in Proposal 3) which ensures that all the program-nodes are safe.
Recall from Optimization I/II of Proposal 3, that while calculating the IN flowmap of a program-
node, we ignore the OUT flowmap of those predecessors that are not safe. Hence, we maintain a set
safeNodes, of the nodes that have been marked as safe during the initialization-step. If any of the
predecessors were ignored for a program-node during its processing, then the program-node is
added to the set underApprox, to be processed in the stabilization-step (see Step IV). Both these
sets are initially empty (see Line 15).
The initialization-step is performed in two parts, as per Optimization II/II of Proposal 3, by
invoking the method underApproximate twice with different initial worklists (entry-nodes vs seed
nodes). Note that the first invocation of underApproximate is not required if every seed node is
also an entry node – in that case, the seed node will always have at least one safe predecessor. The
method underApproximate employs a worklist-based algorithm to process the program-nodes
in the given worklist. Note that since a seed node could also be an entry-node, it may get added

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:46 Nougrahiya and Nandivada

twice to the worklist; to avoid processing any node more than once in the initialization-step,
the set safeNodes is used to ignore the already-processed nodes. The method maintains a set
named unchangedOUTNodes, which contains those nodes whose OUT flowmap do not change
upon their processing during the initialization-step. If all predecessors of a node 𝑛 belong to the
unchangedOUTNodes set, then processing node 𝑛 will not change its OUT flowmap; in this case,
node 𝑛 is added to the unchangedOUTNodes set (Line 10). Otherwise, if there exists even a single
predecessor of 𝑛 which is not present in the unchangedOUTNodes set, then the node 𝑛 is processed
(Lines 11-15), as discussed next.
Before processing any program-node 𝑛, the set of its safe predecessors is calculated first. A
predecessor is added to safePreds (Line 12), if it belongs to a previous SCC (in the topological-
sort order of the SCCs in the SDG), or it has already been processed in the initialization-step (as
maintained in safeNodes). This subset of predecessors is used to calculate the new IN flowmap for
𝑛. If some predecessors of 𝑛 are not in safePreds (and hence the flow information computed for 𝑛
is incomplete), we add 𝑛 to the set underApprox (Line 13), so as to complete its processing in the
stabilization-step. Using the set safePreds, the new IN and OUT flowmaps of node 𝑛 are calculated
by invoking the method processNode.
The method processNode shown in Fig. 18 is similar to the one used in standard IDFA, with
minor changes. We compute IN(n), by only considering the set of safePreds. Then, we invoke the
appropriate analysis specific flow function (F𝑛 ) to compute OUT(n). If the OUT flowmap of the node
changes as a result of this invocation, then the method processNode returns true; otherwise it
returns false. If the method returns false, then node 𝑛 is added to the unchangedOUTNodes set
(Fig. 17, Line 15).
Once the processing of node 𝑛 is complete, it is marked as safe (Line 16). We add to intraSCCWL
all the successors of 𝑛 that are present in the current SCC, except the nodes that are already marked
as safe, and the seed-nodes. We add to intraSCCWL only if (i) the OUT flowmap of node 𝑛 changed
during invocation of processNode, or (ii) the flag unconditionallyAdd was set during invocation
of underApproximate.
As discussed in Optimization II/II, before the second invocation of underApproximate, we want to
mark all the reachable nodes between entry-nodes and up until the seed-nodes as part of safeNodes.
This is achieved by setting the flag unconditionallyAdd during the first invocation. As a result of
this approach, it is ensured that at least one of the predecessors of each seed-node is safe, before
the second invocation of underApproximate.
Step IV: (Stabilization-step) At the end of the initialization-step, all the program-nodes are safe.
However, there may be program-nodes that contain incomplete flowmaps as one or more of their
predecessors were ignored during the calculation of their IN flowmaps. Such nodes were saved in
the set underApprox. Hence, in the stabilization-step, shown in the method stabilize, the worklist
is initialized with the set underApprox (Line 20, Fig. 16), and the standard worklist-based algorithm
is applied until the worklist is empty. Note that none of the predecessors in this step are skipped
during the calculation of IN for a program-node. Further, none of the successor program-nodes
from within the same SCC are skipped from addition back to the worklist if/when the OUT flowmap
of the program-node changes. This is achieved by sending the argument pred(n) for safePreds,
and argument ∅ for skipSuccs (Line 22), when invoking the method processNode.
Step V: Once the flowmaps of all the program-nodes of the current SCC have reached their
(maximum) fixed-point values at the end of Step IV, we compare the states of OUT flowmaps of
exit-nodes with the values stored in the snapshot saved in Step II. If the values for any exit-node
changes, then all its successors from successor SCCs are added to the set globalWL (Line 24).

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:47

1 Function processNodeUsingAccessedKeys(𝑛, L, F, IN, OUT, safePreds): boolean /* Modifies IN and OUT */

2 // Returns true if the OUT flowmap of 𝑛 has changed
3 // safePreds: set of predecessors whose OUT is a safe
. initial estimate
4 if safePreds == ∅ then IN(𝑛) = ⊤; else IN(𝑛) = 𝑝 ∈safePreds OUT(𝑝 );
5 accessedKeys = A K(𝑛); // A K map is used to track the keys accessed in application of F𝑛 .
6 if IN(𝑛) == NULL | | ∃𝑐 ∈ accessedKeys, such that the mapping for c changed in the new IN(n) then
7 OUT(𝑛) = F𝑛 (IN(𝑛));
8 else
9 OUT(𝑛) = IN(𝑛).clone();
10 foreach 𝑐 ∈ accessedKeys do
11 if oldOUT(𝑛) contains 𝑐 then OUT(𝑛)(𝑐) = oldOUT(𝑛)(𝑐);

12 if OUT(𝑛) has changed then return true;

13 else return false;

Fig. 19. Algorithm to recalculate IN and OUT of a program node, while using the accessed-keys heuristic.
B.3 Accessed-Key Heuristic
To use the accessed-key heuristic, in Fig. 17, instead of calling the function processNode, we call a
modified version of it called processNodeUsingAccessedKeys (shown in Fig. 19). In this heuristic
we invoke the transfer function, only (i) if the node is being processed for the first time, or (ii)
if upon calculation of the new IN flowmap, there exists a domain-element whose mapping has
changed from its value in the old IN flowmap (Line 7). Otherwise, the heuristic reconstructs the
new OUT flowmap using the old OUT flowmap and the new IN flowmaps as discussed above.
For this heuristic to be applicable the program-nodes have to be immutable, even under program
change, so that the set of accessed-keys do not change. In case of updates to the contents of a program
node, the condition of immutability can be ensured by treating the change as two operations –
deletion of the old program-node from the super-graph, and addition of a new program-node with
the modified contents.

C USING INCIDFA FOR DATAFLOW ANALYSIS OF PARALLEL PROGRAMS

As discussed in Section 1, iterative dataflow analysis of explicitly parallel programs often requires
adding extra edges to the flowgraph to model inter-thread communication that occurs through
shared memory accesses. These edges are typically introduced between various synchronization
primitives (such as post/wait operations, barrier directives, and so on) depending on the language
semantics [12, 18, 30, 34, 46, 55, 84, 106, 107, 117].

C.1 Background
To demonstrate the applicability of the proposed algorithm for incremental iterative dataflow
analysis of explicitly parallel programs, we use OpenMP [29], an industry-standard API for shared-
memory parallel programming. We now provide a brief introduction to some key synchronization
constructs of OpenMP (in Section C.1.1), followed by a discussion of phase analysis (in Section C.1.2),
which is used to add synchronization edges (in Section C.1.3), and finally an overview of how
standard iterative dataflow analysis can be performed on OpenMP programs using such synchro-
nization edges (in Section C.1.4). It is important to note that the proposed algorithm, as discussed
in Sections 3-4, is agnostic to how inter-thread communication is modeled in the flowgraphs.
C.1.1 OpenMP constructs. Following are the key OpenMP constructs of our concern :
#pragma omp parallel S, denotes a parallel region that generates a team of threads, where
each thread executes a copy of the code S in parallel.
#pragma omp barrier, specifies a program point where each thread of the team must reach
before any thread is allowed to move forward. We use ompBarrier to abbreviate this directive. In

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:48 Nougrahiya and Nandivada

the flowgraph representation of an OpenMP program, we represent each ompBarrier node with
two separate nodes – a preBarrier node and a postBarrier node, with a control-flow edge from
the former to the latter.
#pragma omp flush, is used to flush a thread’s temporary view of the shared memory to make
it consistent with the shared memory. We use ompFlush as a shorthand for this directive.
OpenMP adds implicit flushes at various synchronization points in the program, such as during
lock acquisition and release, at barrier directives, at the entry and exit of critical constructs, and so
on. Similarly, implicit barriers are added by default at the end of parallel loops, parallel regions,
and so on. We assume that all such implicit flushes/barriers have been made explicit.
C.1.2 Phase analysis. In a parallel region in OpenMP, all threads start their execution from the
implicit barrier at the start of the region, until they encounter a barrier on their execution paths.
Once each thread has encountered a barrier (same or different), all the threads will start executing
the code after the barrier, until they encounter the next set of barriers. All such barriers that
synchronize with each other form a synchronization set. Statically, a barrier may belong to more
than one synchronization set. All statements that exist between two consecutive synchronization
sets form a static phase. Each statement may belong to more than one phase. Two statements in
two different phases that do not share any common phase may not run in parallel with each other.
Precise identification of such phases can greatly improve the precision of various static analyses
of parallel programs, as they limit the pair of statements that may communicate with each other
through shared memory. For the purpose of our discussion, any phase analysis should suffice; we
use the phase analysis derived from the concurrency analysis provided by [152, 153].
C.1.3 Synchronization edges. In dataflow analysis of explicitly-parallel programs, special edges (for
example, synchronization or interference edges) are added to the flow graphs to model inter-thread
communication through shared-memory accesses [12, 18, 30, 34, 46, 55, 84, 106, 107, 117].
In order to model inter-thread communication in OpenMP programs, two kinds of synchronization
edges are added in a flowgraph: (i) inter-task edges between ompFlush operations that may share a
phase, and (ii) sibling-barrier edges, from preBarrier nodes to postBarrier nodes corresponding
to barriers that share a synchronization set.
Inter-task edges. In OpenMP parallel regions, different threads (or tasks) may communicate with
each other with the help of shared memory. As per OpenMP standards, a valid communication
can take place between threads 𝑇1 and 𝑇2 through a shared variable, say 𝑣, only if the following
order is strictly maintained : (1) 𝑇1 writes to 𝑣, (2) 𝑇1 flushes 𝑣, (3) 𝑇2 flushes 𝑣, and (4) 𝑇2 reads
from 𝑣. Furthermore, 𝑇2 must not have written to 𝑣 since its last flush of the variable. We model
such perceived communications with the help of inter-task edges, as shown in Fig. 20a. An
inter-task edge is an edge that originates at an ompflush, say 𝑓1 and terminates at (same or different)
ompFlush, say 𝑓2 , such that (i) 𝑓1 and 𝑓2 share at least one common static phase, and (ii) there must
exist some shared variable which is written on an ompFlush-free path before 𝑓1 , and read on an
ompFlush-free path after 𝑓2 .
Sibling-barrier edges. As per OpenMP semantics, at the end of each barrier, all temporary views
of different threads are made consistent with each other and with the shared memory. Consider
a maximal set 𝑆 of barriers that synchronize with each other at the end of a phase 𝑝; this set is
termed as the synchronization set of 𝑝. For each pair of barrier (𝑏1, 𝑏2) ∈ 𝑆 × 𝑆, in order to model
the consistency of temporary views at the end of phase 𝑝, we add a special kind of synchronization-
edge, termed as sibling-barrier edge, from the preBarrier of 𝑏1 to postBarrier of 𝑏2, as shown in
Fig. 20b.
The inter-task edges and sibling-barrier edges can be used to port any standard iterative dataflow

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:49

(a) Inter-task edge (b) Sibling-barrier edge

Fig. 20. Examples of two types of synchronization-edges in OpenMP, denoted by dashed lines. These
edges model inter-thread communications. Solid lines denote one or more paths between two nodes in the
flowgraph.
analysis to explicitly parallel programs, as discussed next.
We obtain a super-graph by adding these inter-task edges to CFGs and call graphs.
C.1.4 Parallel Iterative Dataflow Analysis. We now discuss an extension to the standard iterative
dataflow analysis of serial programs, to make it suitable for parallel programs; we use OpenMP
as the target parallel language. In OpenMP (and other such shared-memory parallelism models),
there are two key portions of data environment for each thread – private and shared. Under the
relaxed-consistency model of OpenMP, each thread is allowed to maintain its own temporary view
of the shared memory, which can be made consistent with the global view of shared memory with
the help of ompFlush directives. The communication between multiple threads resulting from these
directives can be represented as inter-task edges, and sibling-barrier edges, as shown in Fig. 20.
We distinguish the private and shared portions of data-environment, such that the domain of each
flow map consists of two mutually exclusive and exhaustive subsets. Consequently the standard
flow maps can be seen as, IN(𝑛) := INpriv (𝑛) ∪ INshared (𝑛), and OUT(𝑛) := OUTpriv (𝑛) ∪ OUTshared (𝑛),
where the subscript to a map indicates the type (memory locations) of its domain. Now, we discuss
the key extension to serial IDFA to obtain IDFA𝑝 .
Extension 1. In order to model the effects of an inter-task edge (𝑓1, 𝑓2 ) between two ompFlush
directives 𝑓1 and 𝑓2 , for each shared variable 𝑥 that can be communicated over the edge (𝑓1, 𝑓2.
), we
add the following dataflow equation to the serial IDFA; this equation uses the meet operator ( ) of
the underlying serial IDFA.
.
(INshared (𝑓2 )) (𝑥) := (INshared (𝑓2 )) (𝑥) (OUTshared (𝑓1 )) (𝑥) (Ext-1)
Correctness argument. We note that a sound IDFA for serial programs, extended with Ext-1
remains sound in the context of OpenMP. OpenMP API specification [29, Section 1.4.4] specifies the
sequence of events that must be followed for communication to happen between any two threads.
Extension Ext-1 conservatively models all such possible communications that may happen over
any of the inter-task edges. Thus, since the underlying serial IDFA is sound, the extension remains
sound, as no valid flow of shared data may happen at runtime except over the edges which we
model.
Complexity and Precision. For any given IDFA, the worst-case complexity of its corresponding
IDFA𝑝 (upon adding the above proposed two kinds of sycnchronization-edges) remains unchanged.

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
1:50 Nougrahiya and Nandivada

Fig. 21. Percentage improvement in IDFA stabilization-time using IncIDFA when applying the client
optimization, BarrElim, with respect to IncIDFA-NAC, which is a version of IncIDFA with accessed-keys
heuristic disabled. Higher is better.
The precision of IDFA𝑝 depends on that of the underlying phase analysis, as imprecision in phase-
analysis may result in modeling extra inter-task edges than needed.

C.2 Analysing Parallel Programs with IncIDFA

In this section, we discuss the applicability of IncIDFA for analyses of explicitly parallel programs.
Recall that in order to model flow of data between threads through accesses to shared memory
location, the flowgraph representation used for iterative dataflow analysis of parallel programs
comprises of special edges, also termed as synchronization or interference edges [12, 18, 30, 34,
46, 55, 84, 106, 107, 117]. As discussed in Section C, we focus our discussion on two kinds of
synchronization edges used by IMOP – (i) inter-task edges, and (ii) sibling-barrier edges. Together,
these two kinds of edges represent most types of synchronization edges that have been discussed
in the literature.
We notice that IncIDFA is applicable as is for the case of iterative dataflow analyses on such
flowgraph representations. The special edges, as well as the special nodes (such as ompFlush,
preOmpBarrier, and postOmpBarrier), are treated just like any other edge or node in the flowgraph.
Note that the definition of meet operation remains to be the same in IncIDFA, as in the case of
CompIDFA – only the dataflow information corresponding to shared memory locations (if any) are
considered during the meet operation for the OUT flowmaps of the sources of incoming sibling-
barrier edges at any preOmpBarrier.

D MISCELLANEOUS DATA
Performance impact of accessed-keys heuristic on K2. In Section 6.2, we have provided
evaluation numbers for Nanda, to assess the impact of accessed-keys heuristic by comparing
IncIDFA with IncIDFA-NAC. Now, we present the numbers for our evaluations on K2. Fig. 21 shows
the percentage improvement using the heuristic, for K2. The baseline numbers, for IncIDFA-NAC,
are present in Column 14 of Fig. 10. We see that IncIDFA consistently outperforms IncIDFA-NAC;
improvements up to 54.12% (geomean 26.92%). Since the reasoning and observations with K2 remain
same as that for Nanda, we skip the discussion for this graph.
In Fig. 22, we show the total number of transfer-function applications that were skipped as a result
of the accessed-keys heuristic, normalized with respect to the number of applications in the baseline
IncIDFA-NAC. We notice that there is a significant reduction in transfer-function applications with
this heuristic, with maximum for art-m at 84.41%, and geomean of 59.91%. Consequently, this leads
to improved compilation time, as discussed in Section 6.2.
The BarrElim set of optimizations. In Fig. 23, we list key optimization passes that form the
set BarrElim. The details of this pass are given in the paper by Nougrahiya and Nandivada [93].
Hence we skip the details here. As noted by the authors, BarrElim is a powerful set of optimization
passes for OpenMP programs, achieving performance improvements of up to 5% on top of the

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.
IncIDFA: An Efficient and Generic Algorithm for Incremental Iterative Dataflow Analysis 1:51

Fig. 22. Total number of applications of transfer-functions across all stabilization triggers that were skipped
when performing BarrElim optimization, for various configurations normalized with respect to the number
of applications when accessed-keys heuristic is disabled (set to 100). Higher is better.
Optimization Pass in IMOP Description
1. Redundant barrier remover removes barriers in absence of inter-thread dependences
2. OmpPar expander expands the scope of parallel-regions upwards and downwards
3. OmpPar merger merges two consecutive parallel-regions, if safe
4. OmpPar-loop interchange interchanges a parallel-region with its enclosing loop, if safe
5. OmpPar unswitching interchanges a parallel-region with its enclosing if-stmt, if safe
6. Variable privatization privatizes OpenMP shared variables, if safe
7. Function inliner selectively inlines monomorphic calls containing barriers
8. Scope remover removes redundant encapsulations of blocks in the given node
9. Unused-elements remover removes unused functions, types, and symbol declarations

Fig. 23. List of key passes in IMOP that belong to the BarrElim set of optimization passes. This figure has
been reproduced (and summarized) from the paper by Nougrahiya and Nandivada [93].
already-optimized code generated by gcc with the -O3 switch. Therefore, in our evaluations we use
the BarrElim set of optimization passes to generate the stabilization-triggers (using Homeostasis),
which are then handled by our proposed incremental-update algorithm in order to stabilize the
dataflow solutions in response to the program-changes (as provided by Homeostasis).

Proc. ACM Program. Lang., Vol. 2, No. 1, Article 1. Publication date: January 2025.