Report on "
Composing Dataflow Analyses and Transformations
"
by S. Lerner, D. Grove and C. Chambers
Report by Konstantinos Bitsakos, Dec. 5 2002
This paper addresses the problem of writing dataflow analyses in a modular way and combining them in order
to
create a super
-
analysis. Their approach is to export the results of an individual analysis to all other analyses
using flow graph transformations. So, depending on the input values and the current node of the program graph,
the result (flow function) of each individual analysis can be a set of abstract values or a new sub graph to
replace the current node. Applying the super
-
analysis recursively to the new sub graph can lead to further graph
transformations (by the same or other analyses). When this procedure reaches a fixed point, then the current
state of the graph is saved. The most common statement (node) transformations are:
•
ReplaceResult
: replacement with another statement (e.g. constant
-
folding)
•
ReplaceGraphResult: replacement with an entire subgraph
of statements (e.g. inlining)
•
DeleteResult
: deletion (e.g. dead code elimination)
Inside the paper they say that "a replacement graph must have the same number of input and output edges as the
node it replaces and its nodes and edges must be unique". At th
e same time they give an example, where they
replace an "if" statement with a "goto" statement. It seems to me, that this replacement is not valid according to
their requirements.
From a mathematical point of view, they start with the formal definition of
a single Analysis followed by
Transformations (
AT
), next they integrate the Analysis and the Transformation (
IT
) and at the final stage they
combine multiple analyses to create a super
-
analysis (
CA
). At each step they formulate the soundness criteria
using
results from previous steps and they prove that their framework is sound.
It is clear from the context, that their framework can only integrate analyses with the same direction (forward or
backward).
Interesting points:
•
Their framework is independent of
the exact representation of the program. Most of their work is done in
the Vortex compiler, which uses a standard CFG representation. Recently they experimented with
Whirlwind compiler, which uses a dataflow graph (DFG) representation with control
-
edges.
•
How do they select between different replacement graphs (what is the PICK function they mention)?
Inside a technical report they say that clients of the composed analysis interface, specify the order of
component analyses when they create a composed analy
sis and according to this order the first component
analysis to choose a transformation takes precedence over any later analyses. They also mention that the
experimental results show that there is a natural ordering of transformation passes.
•
Intraprocedur
al analysis
. In this paper they don’t say much about intraprocedural analysis. In a referenced
report they say that intraprocedural analysis determines whether the analysis is flow
-
sensitive or insensitive,
but they don’t specify how this is done.
•
Interpr
ocedural analysis
. Interprocedural analysis is based on the intraprocedural framework. The
interesting thing about it, is that you can define various levels of context sensitivity, by defining how many
input
-
output pairs the framework keeps for each functi
on. For example, if it keeps only one pair per
function, then the analysis will be context
-
insensitive. In the presence of recursion the framework initially
selects the most optimistic approximation for a recursive function and replaces each subsequent fun
ction
call with the same calling context with the optimistic output. If at the end of the analysis, the real output is
