Variable Dependence AnalysisTechnical Report: TR-10-05

Chris Fox1, Mark Harman2, Youssef Hassoun3

1. Department of Computer Science, University of Essex, Wivenhoe Park, Colchester, CO4 3SQ, UK2.Department of Computer Science, King’s College London, Strand, London WC2 2LS, UK3. Department of Computer Science, King’s College London, Strand, London WC2 2LS, UK

Abstract

Variable dependence is a source code analysis problem, related to slicingand chopping, in which the aimis to determine the set of variables that can affect the values of given program variables at specified pointsin the program. This paper describes an approach to solving the problembased on transforming programcode into an intermediate language without preserving concrete semanticsbut keeping variable dependencerelations intact. Interestingly the transformation phase need only preserve variable dependence, therebyadmitting useful transformations that fail to preserve standard semantics (but do preserve variable depen-dence). The paper describes an implementation of a variable dependence analysis system called V,illustrating the application of non–meaning–preserving transformation, together with an empirical study ofperformance optimisation steps.

Key words: Variable Dependence Analysis, Slicing, Program Transformation.

1. Introduction

Variable dependence analysis is the problem of determiningfrom a function, procedure ofblock of source code, the set of ‘input’ variables upon whoseinitial value a chosen computationdepends. The choice of which variables form a valid set from which to draw inputs dependsupon the context of the analysis. For instance in a function or procedure, the ‘input’ variables aretypically taken to be the formal parameters of the function,while for a block of code they maysimply be variables whose value is used before it is defined.

Variable dependence analysis is a dependence analysis thattraces control and data depen-dences in a similar way to other program dependence analysessuch as slicing [20,32] and chop-ping [22]. Like slicing, the criterion, is a pair (V,n), but instead of returning a set of statementsthat affect the value computed in variablesV at linen, the algorithm returns the set of variablesupon which the computation depends. Variable dependence has applications in program compre-

Preprint submitted to Elsevier 26 April 2010

while (a>1) {

c=c-1;

b=b+1;

x=x+y+b;

y=y+z;

p=p+1;

z=z+1;

}

Fig. 1. Variable Dependence Example

hension [5], where it can help to understand the impact of a change and indebugging and testing[17], where it can reduce the search space for unit test data generation.

This paper describes the design and implementation of the V system, and in particular, itscombination of transformation and analysis and its use of memoisation. V is a system for vara-iable dependence analysis of source code written in C. It is currently used by DaimlerChrysleras part of their approach to automated test data generation.

The V tool was first introduced by Harman et al. [16]. The present paper is an extensionof this previous workshop paper describing an augmented system that encompasses additionalfunctionality and a wider target language. The present paper also extends the earlier workshoppaper with additional implementation details and a formalisation of the analysis algorithm.

There are different kinds of variable dependence relationships. For example, a variable can bedata dependentor control dependenton other variables. Data depdendency arises fromde f,usepairs of program points and can be described as follows. A variablev defined atn is said to bedata dependent on another variablev′ at n′ if the latter is used inn and there is a an executionpath fromn′ to n on whichv′ is not modified. On the other hand, control dependency arisesfromprogram branching due to conditional statements or function calls. A variablev defined atn issaid to be control dependent on another variablev′ at n′ if the execution or non-execution ofndepends on the truth value of the expression involvingv′ atn′.

We explain the ideas of variable dependence relationships through the code fragment in Fig-ure1. This figure depicts a simple program with a singlewhile-loop. In this example, the vari-ablex at the end of the program depends upon the initial values of the variablesz, y, b, a, x. Theexample indicates the way in which variable dependence can be loop carried (the dependenceof x upony) and involves control dependence (the dependence ofx upona) as well as datadependence (all other dependences in this example).

The computational effort required to find a suitable test input (that causes execution to followa required branch) is closely related to the size of the spaceto be searched. The size of the searchspace is defined by the number of input variables considered to be relevant to the computation ofthis predicate. Not all input variables contribute to the computation of every branch predicate. Incases where a predicate depends only on a subset of the input variables, it is wasteful to search theentire input space. V supports search space reduction by finding the subsets of input variablesrelevant to the branches of a program. The approach adopted is similar to the chaining approachof Ferguson and Korel [15].

The principal contributions of the paper are as follows:

2

(i) The paper introduces formal definition of the variable dependence algorithm.(ii) The paper presents description of the implementation of this approach in a tool called

V.(iii) The paper introduces two techniques for performance improvement. A Memoization ap-

proach and a set theoretic optimization on variable dependence sets, based on propertiesof variable dependence. The paper also presents an empirical study of their effects.

The core language allows computation of variable dependence for the core language, whileits results are applicable to the full language. As will be seen, the transformation into the corelanguage also includes novel transformation steps, available only for this application, becausethey need preserve only variable dependence, not traditional functional meaning.

The rest of this paper is organised as follows. Section??shows the relationship between slicingand variable dependence. Section3 describes the overall architecture and the implementationofthe V system. Section?? introduces the core language used by the slicing engine at its heart.Sections?? and 3.1 describe the transformation and variable dependence analysis phases ofthe system in more detail and Section4 presents some initial empirical results concerning theperformance of the analysis phase. Section?? gives a worked example. Section5 deals withrelated work. Section6 ends the paper with some concluding remarks.

2. Variable Dependence Analysis Approach

In this section, our approach to variable dependence analysis is described. The approach isbased on rewriting program code in an intermediate core language using a subset of theC pro-gramming language. The transformation algorithm simplifies the analysis by removing seman-tics information irrelevant to dependency relationships among program variables. The analysisalgorithm is expressed as a transformation mapping programstatements combined with theirvariables into program statements.

2.1. The Core Language

The core language consists of a simple subset of intraprocedural C. The subset does not re-strict expression notation, but only supports a limited setof statement constructs. Procedures assuch are also not supported directly. More complex statement constructions and non-recursiveprocedures are instead interpreted by translation into thecore language. The syntax of the corelanguage is defined in Figure2.

A program in the core language consists of a set of function definitions, the bodies of whichare the statement sequences of statements drawn from the syntactic classC. The core allows forfunction definition but not function call. Function calls are unfolded in the transformation phase.Unfolding is known to have worst case exponential growth in the depth of call tree. However,this does not lead to problems in practice, because

(i) The algorithmic complexity of function unfolding is exponential in the depth of the calltree and since the depth of the call tree grows logarithmically with its size, unfoldingfunctions does not lead to exponential explosion.

(ii) At the unit level, program size is normally relatively small.(iii) Many applications in the industry, such as those in embedded systems tend to have shallow

flat call trees.

3

〈expression〉 ::= 〈expression〉1〈binary op〉 〈expression〉2

| !(〈expression〉)

| 〈identifier〉

| 〈number〉

| 〈identifier〉[〈expression〉]

| 〈expression〉1?〈expression〉2 : 〈expression〉3

〈binary op〉 ::= + | − | ∗ | % | == | != | && | || | . . .

〈statement〉 ::= 〈identifier〉 = 〈expression〉;

| if (〈expression〉) 〈statement〉

| if (〈expression〉) 〈statement〉1else 〈statement〉2

| while (〈expression〉) 〈statement〉

| {〈statement〉1 . . . 〈statement〉n}

| goto 〈label〉;

| 〈label〉:

Fig. 2. The Syntax of the Core Language

The core language was chosen to facilitate easy translationfrom full C, whilst allowing thecontrol flow relationships of the full language to be preserved by translation. Thewhile loopandif statement are retained as the paradigms of selection and repetition. All conditional anditeration constructs can be converted into these core constructs in a way that preserves the controldependence relationships between variables. A smaller core language would have been possible[30], but the objective was to retain a simple approach to control dependence, in which a predicatecontrols the statements mentioned in its body. This greatlyreduces the effort required to computecontrol dependence information needed by the slicing and dependence analysis algorithm for thecore language. It is also easier to manually verify the individual translation and dependence rulesthan it is to check rules that compute the dependencies directly from more esoteric programconstructs.

2.2. Program Transformation

The transformation algorithm transforms C programs into the core language, the syntax ofwhich was defined in Figure2. The overall transformation algorithm is as follows:Step 1 Insert Dependence Criteria AssignmentsStep 2 Globalise local scopeStep 3 Build function and procedure symbol tableStep 4 Unfold procedure callsStep 5 Globalise local scopeStep 6 Statement-level transformation rulesThe remainder of this section describes each step in more detail.

4

2.2.1. Step 1 (dependence criteria)This step inserts assignment statements to pseudo variables to capture the variable dependence

criterion specified by the user. These assignments allow dependence at arbitrary points in theprogram to be computed in terms of corresponding dependences at the end of the program. Forexample, to insert a criterion〈{v1, v2, . . . , vn}, p〉 wherev1, . . . , vn are program variables, andp isa point of interest, an assignmentπ = π + v1 + . . . + vn is inserted at the point of interest, whereπ is a pseudo variable not otherwise used in the program.

The fact that the expression assigned to this pseudo variable involves additions is an arbitrarychoice that just ensures that the variablesv1, . . . , vn are referenced. The pseudo variable itselfis also included as a referenced variable in order to correctly compute dependence onv1, . . . , vn

when the point of interest lies inside a loop.The point of interestp is given by identifying a particular expression in the program, rather

than a statement, for example, expressions are given uniqueidentifiers in the AST representationof the program under analysis. Expression identifiers can beused to define dependence criteria,in which case, all of the variables mentioned in that expression are included in the criteria.

2.2.2. Step 2 (globalisation)Step 2 creates new, previously unused variables and uses these to replace, consistently, the

occurrences of local variables, thereby removing local scope and ensuring that all variables are,effectively, global variables. This simplifies the variable analysis phase, particularly in the pres-ence ofbreak andreturn statements. Subsequent transformation steps replace bothbreak andreturn statements with forward jumps, but they retain the propertythat they allow criteria topass from an outer to an inner scope. Without globalisation,the scope rules would have to betaken into account every time such a statement is encountered and, potentially, separate treat-ments would be required for each variable, depending upon its scope binding.

2.2.3. Step 3 (symbol table)In this step, a mapping is created from procedure and function names to their bodies. This is

a pre-requisite for Step 4. There is a sense in which it is not really a transformation step itselfbecause it does not affect the program, but it is required in order to unfold the procedures byreplacing procedure calls with the corresponding program code.

2.2.4. Step 4 (procedure and function unfolding)Step 4 uses the procedure symbol table that was created in Step 3 to unfold each call to a pro-

cedure call in the bodies of procedures. Clearly this is not possible in the presence of recursion.Unfolding procedures may seem like a wasteful and rather crude transformation to perform.

However it has a number of advantages that make it worthwhilein practice. Specifically, thesubsequent analysis phase is not only considerably easier to express, it is also faster. This extraspeed is obtained at the expense of space, but not precision.The analysis program needs only beintraprocedural; the unfolding of procedure calls takes account of the calling context by intro-ducing assignments to the formal parameters from the actualparameters of the call. This meansthat during the analysis there is no additional overhead in taking into account the calling context.

Function calls are transformed to procedure calls with an additional fresh global variable tocommunicate the result to the caller. While this may not be good programming practice, thecode will be seen only by an analysis tool and not by a human. Furthermore, the all-importantdependence relation remains invariant.

5

2.2.5. Step 5 (second globalisation)The fifth step repeats the globalisation process. This is required because Step 4 creates addi-

tional local scope when formal parameters are transformed into assignments to new local vari-ables. This second globalisation process has to take place after the unfolding of procedures inorder to correctly account for formal parameters. However,the globalisation of procedure bodiesalso has to take placebeforeunfolding, in order to ensure that after unfolding, each mention ofthe same local variable is mapped to the same global variable, regardless of the call instance.Therefore, globalisation has to be performed twice: once before unfolding and once after.

2.2.6. Step 6 (statement transformations)This final step performs the statement level transformations. These simplify language under

consideration. For instance, the C language offers many ways of assigning a value to a variable,through assignment expressions, using assignment operators like += and &= and through theuse of pre- and post- increment and decrement operators. Sequencing of assignments withinexpressions is also possible using the comma operator. When such expressions are encoun-tered as statements, they are each transformed into ‘regular’ assignment statements of the form〈identifier〉 = 〈expression〉;. Thedo andfor looping constructs are converted towhile con-structs. This means that only a single looping constructionneed be considered in the analysisphase. This is a saving in development effort, as correct account of looping constructs requiresa fixpoint computation, as explained in Section3.1and memoisation, as explained in Section4.It also has a positive benefit on testing and verification of the approach, since the transformationsteps can be readily understood and verified in isolation, leaving only a single looping constructto be tested.

The ‘jump’ statementsbreak, continue andreturn are converted to forwardgoto state-ments. Additional labels are introduced in order to capturethe targets of thesegoto statements.This allows all these three forward jumps to be treated identically in the analysis phase. Thisunification of statement construct offers similar benefits for understanding, development andverification as the unification of looping constructs.

The next subsection gives an example of such a transformation, where a C statement witha relatively complex semantics is transformed into the corelanguage in a way that preservesvariable dependencies but which avoids the additional complications that would be required topreserve full functional equivalence.

2.2.7. Example: transformingswitch statementsThe transformation functionR〈label〉〈statement〉 produces a statement or statement sequence〈statement〉′ from a statement of statement sequence〈statement〉. 〈statement〉′ is identical to〈statement〉 except that all occurrences of thebreak statement have been replaced by the state-ment goto 〈label〉;. The transformation of aswitch statement converts theswitch into anested conditional, usingR〈label〉〈statement〉 to replacebreak statements with forward jumpsthat exit the nested structure. More formally, theswitch statement of Figure3 is transformedinto the nested conditional statement of Figure4.

Notice that this transformation doesnot preserve functional equivalence. It does not need to.It need only preserve the variable dependence relation. Theoutermost conditioned predicate issimply 〈expression〉, since the variable dependence upon the reference variableof 〈expression〉 isall that is needed. Furthermore, the inner tests are merely present to create a conditional structureto replicate the optionality of theswitch, but the dependence upon〈expression〉 has already been

6

switch (〈expression〉) {

case c1 : 〈statement〉1...

case cn : 〈statement〉n

default : 〈statement〉d

}

Fig. 3. A genericswitch statement

if (〈expression〉) {

if (1) {

if (1) {

.

.

.

if (1) {

if (1) { R〈label〉〈statement〉1 }

R〈label〉〈statement〉2 }

.

.

.

R〈label〉〈statement〉n−1 }

R〈label〉〈statement〉n }

else 〈statement〉d

〈label〉 :;

Fig. 4. A transformedswitch statement

accounted for by the outermost〈expression〉, and so the test is not repeated. This does not pre-serve functional equivalence, but does allow a correct computation of variable dependence, anddoes so more efficiently than the fully functionally equivalent version of the nested conditional.

Moreover, the transformation to this nested conditional considerably simplifies the treatmentof the problem of fall-through cases inswitch statements. These fall-through cases are a pecu-liar feature of Cswitch statements in which each case is performed and execution canfollowthrough to the cases below where there is nobreak statement to terminate the case.

It is also worth noting thatbreak statements need not occur merely at the end of a case,and there may be manybreaks within the program code handling each case. For example, itispossible to createswitch statements in which there is a nested conditional structurefor somecase and where this conditional has some paths containingbreak statements, while others simplycause execution to fall through to the lexically succeedingcase.

The transformational flexibility available to the initial stage is considerable, since only variabledependence need be preserved. For example, a more radical transformation which suggests itselfwould be to reverse the statements order of all the statements in the program under inspectionbefore applyingforward dependence analysis in order to computebackwarddependence. The

7

result would be equivalent to variable dependence analysisas described here, but with the advan-tage of employing a tail recursive algorithm, which lends itself to optimisation. This possibilityremains a topic for future work. However, the current implementation does contain a number ofmemoisation based performance enhancements, described inthe next section.

2.3. Variable Dependence Algorithm

In this section, a variable dependence analysis algorithm is presented as a function on corelanguage statements. According to the core language syntaxdefined in Section2.1, there are ef-fectively five different types of statements: assignment, conditional (if), loop (while), sequence(of statements), and goto. The function takes a set of identifiers (variables) together with a state-ment as parameters and delivers a set of identifiers of the statement’s expression that are controland data dependent on the parameter variables. The set of parameter variables with which theanalysis starts is chosen to be the set of identifiers found ina program expression or a statementand is called the dependence criterion. As the program is analysed in sequential order, the startingset of variables representing the dependence criterion changes depending on the program controland data flow.

Let S denote the set of program statements expressed in the core language, andV the setof program identifiers. Avda function is a map that takes as input a program core languagestatement and a set of identifiers and produces as output a setof variables that are dependent onthe given parameter set.

vda : V × S −→ V

In the following, [[s]] where s ∈ S denotes “approximate” semantics ofs resulting from thetransformation of original program statement with “concrete” semantics into the core language-as described in Section2.2on statement transformation.

2.3.1. An assignment statement:[[v = E; ]]There are two cases depending on whether the assigned variable (v) is of interest, i.e., belongs

to the criterion set of variablesV as it reaches the statement, or not. In the case wherev < V,the statement is not considered and the output set is identical to the original setV. Otherwise,a set containing all input variables (apart fromv) together with all the variables referenced inexpressionE is delivered

In terms of thevda transformation, the two cases can be more formally expressed as follows.Here,Re f(E) denotes all variables referenced in expressionE [1].

vda (V, [[v = E]]) = V, i f v < V

vda (V, [[v = E]]) = (V − {v}) ∪ Re f(E), i f v ∈ V

2.3.2. An if-statement:[[ i f P then S1 else S2]]Here,S1 andS2 represent sets of statements and there are two cases to be considered.(1) the input variables are independent ofS1 andS2, or, in other words, the latter do not affect

the input variables. In this case, the input set of variablesV is delivered.

8

vda ([[ i f P then S1 else S2]] ,V) = V,

where vda(S1,V) = V and vda(S2,V) = V

(2) statements inS1 and in S2 do affect the input variables. In this case, the variables ofthe such statements define, in combination with variables referenced in the predicateP,the output set of variables. We note that the set of variablesreferenced in the predicate,Re f(P), becomes relevant (due to control dependency) only if subsets ofS1 or S2 thataffect the input variables are not empty.

In the following,V1 andV2 represent, respectively, sets of variables in those statementsof S1 andS2 that affect the input variables, or, in other words, on which the input variablesare dependent.

vda ([[ i f P then S1 else S2]] ,V) = V1 ∪ V2 ∪ Re f(P),

where vda(S1,V) = V1 and vda(S2,V) = V2

An if-statements without “else”, that is, with emptyS2 = [[ ]], represents a special case andcan be treated in the same way.

2.3.3. A sequence of statements:[[S1; S2]]We assume that the statement are executed in the given order from right to left, i.e.S2 followed

by S1. If a sequence of sets of statements have no effect on the input set of variablesV, theoriginal setV is returned. Otherwise, the set of variable dependencies resulting from executingS2 is used as variable criterion in combination withS1.

vda ([[S1; S2]] ,V) = V′,

where vda(S2,V) = V2 and vda(S1,V2) = V′

2.3.4. A while loop:[[while(P) do S]]In the case where the loop bodyS does not affect the criterion input variable set, the input set

of variablesV is delivered.

vda ([[while(P) do S]] ,V) = V, where vda(S,V) = V

In the other case whereS affectsV, vda computes the set of variables corresponding to thefixed point. This is the smallest set of variables that containsV and that remains invariant afterthe loop body is completed. The fixed point corresponds to thecondition V′n ⊆ V′n+1 in thefollowing expression. The returned set of criterion variables combines the input variables set, theset corresponding to the fixed point and the variables referenced in the predicateP.

In the following,S′i represents the subset of statements of the loops body (S) that affects thecurrent set of criterion variables after theith iteration of the loop.

9

vda ([[while(P) do S]] ,V) = V′,

where vda(S,V) = V′1 and

vda(S′1,V′1 ∪ Re f(P) ∪ V) = V′2) and

vda(S′2,V′2) = (S′3,V

′3) and

...

vda(S′n,V′n) = V′n+1

with V′n ⊆ V′n+1 and V′ = V′n ∪ Re f(P) ∪ V

2.3.5. A goto statement:[[goto L]]For a goto statement with labelL, vdacomputes the criteria to whichL is mapped and updates

the criteria as new labels are encountered. Given the mapping information,vdacan proceed tocalculate variable dependencies.

3. The V Implementation of Variable Dependence Analysis Approach

V is a Prolog implementation of the variable dependence analysis approach described inthe previous sections. Precisely, V uses SWI-Prolog1 to implement a syntax-directed variabledependence algorithm, derived from the parallel slicing algorithm of Danicic and Harman [9].The reasons for choosing Prolog are manifold. Prolog itselfis a versatile meta-programminglanguage. Related to this, recursive pattern matching rules with mappings to some interpretation(in this case dependence) can be expressed in a fairly natural way. This feature helps with rapiddevelopment, modulo the issue of having to thread values through arguments.

Other languages, e.g., Haskell and ML, and other implementations of Prolog also have some ofthese features, but essentially the most important featurein this case is SWI-Prolog’s SGML/XMLparser. It is one of the fastest, most versatile and compliant SGML/XML parsers. It can parse withor without a DTD, give informative error messages about the DTD (which actually helped iden-tify bugs in the third party C to XML parser) and generate a DTDfrom a sample file. It alsohas a hybrid event-based/tree-based parser, so that one can set an event that triggersa tree-basedparse of the matching entity. As the SWI-Prolog parser outputis a Prolog term, it naturally feedsinto the pattern-matching and meta-programming paradigm that Prolog supports. SWI-Prologis appropriate for that kind of analysis problem V addresses. SWI-Prolog also supports thecreation of stand-alone executables under Linux and MS–Windows from a common source.

The overall implementation is split into three main components: a transformer, an analyser anda user interface. The transformer converts the AST representation of the source code, expressedas an XML tree, into the core language. The core language representation becomes the subjectof the analysis phase. This follows the approach first suggested by Landin [24]. The interfaceprovides means of input and output, which allows users to manipulate the system, to define thecriteria for analysis and to receive analysis results.

The transformation algorithm preserves the variable dependence relations though not neces-sarily the full semantics of the original program. The transformation serves to simplify the role

1 SWI-Prolog is available under the GNU Public Licence fromhttp://www.swi.psy.uva.nl/projects/SWI-Prolog/.

10

of the analyser. The overall system accepts ANSI C. However,some language features such asrecursion and backwardgoto statements are not currently supported.

3.1. The Variable Dependence Analyser

The Prolog rules used by V are slicing rules for the the core language that yield variabledependence information as a by-product. The rules are attractively simple to define. The essenceof the slicing engine, in Prolog, is presented in Figure5. It largely consists of pattern matchingand rewriting rules for the core language constructs. The auxiliary predicates (for which detail isnot provided) are described in English in Figure6.

Although Prolog allows the expression of pseudo non-deterministic algorithms via backtrack-ing, our simple slicing algorithm is fully deterministic, and hence has no need to exploit thisProlog feature. As the algorithm is deterministic, the implementation can make extensive useof the cut operator (!) to eliminate irrelevant “choice points,” and hence reducememory con-sumption. However, these details are not relevant to the values of slices and variable dependencecomputed and so they are omitted from the exposition.

Space does not allow the full details of these rules to be given. However, they are relativelystraightforward and the reader can easily reconstruct all but theempty statement predicate,the definition of which determines the precision of the slicing algorithm in the presence of un-reachable code. The current implementation makes some attempt to recognize unreachable code(which should be removed from all slices regardless of the slicing criterion), but does not detectall cases. Of course, in general, determination of whether or not a piece of code is unreachableis undecidable [1], but it remains open as to whether unreachable code can be determined at thelevel of abstraction used for computing variable dependence [8,25,33]

The parsing details are left abstract in the exposition. In the implementation, the pattern match-ing and rewriting is actually expressed in terms of selectors and constructors operating on Prologrepresentations of an XML encoding of the relevant constructs. To aid comprehension, and avoidcluttering the details of the algorithm, the rules are givenin the form of quasi quoted [[. . .]] Cconstructs in the figure.These quotes (or ‘syntactic brackets’) are typically used to distinguishthe language under analysis from the language used to perform the analysis [28].

The predicateslice in Figure5 has six arguments. Three are input arguments and three areoutput arguments. These arguments retain this distinct role throughout the computation of slicesand variable dependence. The predicate call

slice(MapIn,MapOut,

StatementIn,CritIn,

StatementOut,CritOut)

takes as input the representation of a C program statementStatementIn and a criterion (a list ofvariables of interest)CritIn. It produces as output a sliceStatementOut and an output criterion(a list of variables upon whichCritIn depends),CritOut. The sliceStatementOut is the endslice [23] of the statementStatementIn with respect to the list of variablesCritIn. CritOutis the list of variables whose initial values can, in principle at least, determine the values of thevariables inCritIn during the course of some execution of the object language program codeStatementIn.

In addition,slice also takes, as input, a mapping from labels (goto targets) to slicing criteria(lists of variables),MapIn and produces an updated mapping,MapOut as an output. This mapping

11

slice(MapIn,MapIn,[[ I = E; ]],CritIn,[[ I = E; ]],CritOut) :-

intersection(CritIn,[ I ],Intersection),

not(Intersection = []),

collect refs([[E]], VarNamesR),

subtract(CritIn,[[ I ]],Difference),

union(Difference,VarNamesR,CritOut).

slice(MapIn,MapIn,[[ I = E; ]],CritIn,[[]] ,CritIn).

slice(MapIn,MapOut,[[if(E) C]],CritIn,[[if(E) C′]],CritOut) :-

slice(MapIn,MapOut,[[C]],CritIn,[[C′]],CritThen),

not(empty statement([[C′]])),

collect refs([[E]] ,PredRefs),

big union([CritIn,CritThen,PredRefs],CritOut).

slice(MapIn,MapOut,[[if(E) C1 else C2]],CritIn, [[if(E) C′1 else C′2]],CritOut) :-

slice(MapIn,ThenMapOut,[[C1]],CritIn,[[C′1]],CritThen),

slice(MapIn,ElseMapOut,[[C2]],CritIn,[[C′2]],CritElse),

(not(empty statement([[C′1]]));not(empty statement([[C′2]]))),

collect refs([[E]],PredRefs),

union(ThenMapOut,ElseMapOut,MapOut),

big union([CritThen,CritElse,PredRefs],CritOut).

slice(MapIn,MapIn,[[if(E) C]],CritIn,[[]] ,CritIn).

slice(MapIn,MapOut,[[while(E) C]],CritIn,[[while(E) C′]],CritOut) :-

slice(MapIn, MapOut,[[C]],CritIn,[[C′′]],FirstCritOut),

not(empty statement([[C′′]])),

collect refs([[E]],PredRefs),

find fixpoint(MapIn, MapOut’,PredRefs,[],FirstCritOut,[[C]], CritIn’,FixPointCrit),

union(FixPointCrit,CritIn,CritOfSlicedBody),

slice(MapIn,MapOut,[[C]],CritOfSlicedBody,[[C′]],CritOutFromSlicedBody),

big union([CritOutFromSlicedBody,PredRefs,CritIn],CritOut).

slice(MapIn,MapIn,[[while(E) C]],CritIn,[[]] ,CritIn).

slice(MapIn,MapOut,[[ {C1 ... Cn−1 Cn}]],CritIn,{C′1 ... C′n−1 C′n},CritOut) :-

slice(MapIn,MapInternal,[[Cn]],CritIn,[[C′n]],CritInternal),

slice(MapInternal,MapOut[[ {C1 ... Cn−1}]],CritInternal,[[ {C′1 ... C′n−1}]],CritOut).

slice(MapIn,MapIn,[[goto L; ]], CritIn,[[goto L; ]],CritOut) :-

lookupMap(MapIn,[[L]],CritOut).

slice(MapIn,MapOut, [[L :]],CritIn,[[L :]],CritIn) :-

updateMap(MapIn,[[L]],CritIn,MapOut).

find fixpoint(MapIn,MapIn, PredRefs,PrevButOneCrit,PrevCrit, Body, CritIn,PrevCrit) :-

subset(PrevCrit,PrevButOneCrit).

find fixpoint(MapIn,MapIn,PredRefs, PrevButOneCrit,PrevCrit,Body,CritIn,FinalCrit) :-

big union([PrevCrit,PredRefs,CritIn],NewCritIn),

slice(MapIn,MapOut’,Body,NewCritIn, Body2,CurrentCrit),

find fixpoint(MapOut’,MapOut,PredRefs,PrevCrit,CurrentCrit,Body,CritIn,FinalCrit).

Fig. 5. Core Language Slicing Algorithm in Prolog Pseudo Code

12

Prolog Predicate Purpose

big union Forms the distributed union of a set of sets

collect refs Determines the referenced variables of an expression

empty statement Determines whether a statement contains only dead code

and empty structures

lookupMap Find the criteria to which a label is mapped

updateMap Update a map to record a new mapping from a Label to a criterion

Fig. 6. Details of additional Prolog predicates required bythe slicer/variable dependence analyser

information is required in order to slice, and hence computevariable dependency informationfor program code involvinggotos. The mappingMapIn records the slicing criterion that wascomputed for any labels as they are encountered. This mapping is updated as new labels arediscovered. In the computation of fixed points (for the computation of the variablesCritOutfor while loops) the mapping is also updated for previously encountered labels that are re-encountered as the iteration to the fixedpoint proceeds. Theupdated mapping is given inMapOut.

Each of the rules for computing slices are relatively straightforward. The assignment and con-ditional rules implement, in Prolog, the traditional dataflow equations used for slicing [9,32].Each rule is processed according to Prolog’s ordered pattern-matching rules. The rule that keepsa C statement in the slice is considered first, using the default assumption that the statement maycontain information that has an impact on the variables in question. If it turns out that this as-sumption is incorrect, and the C statement has no impact on the values of the variables in theslicing/dependency criteria, then the rule fails. The entire C statement is then removed from theslice by the clause that follows, and the dependency criteria is left unchanged.

The rule for slicing awhile loop deserves a little further explanation. The rule first slices thebody of the loop. If this is empty, then the slice should remove the entirewhile loop, hencethe ‘not empty’ test in the second line of the first clause forwhile loops. However, if the loopis to be retained, it is necessary to compute the smallest setof variables that contains the inputcriterion (CritIn) and that remains invariant after the loop body is completed. The predicatefind fixpoint has the role of computing this criterion, giving the result in FixPointCrit.However, the value ofFixPointCrit is not the ultimate resulting criterion, as the loop may notbe executed (so the initialCritIn should be retained), and should always contain the predicatereferenced variables (soPredRefs is retained).

The parser treats C program labels as statements. The rules for labels andgoto statements,merely record and restore, respectively, the criterion associated with the label mentioned in thestatement.

3.2. Architecture and Modules

Figure7 shows a view of the V system as a processing machine which expects three inputparameters and gives one output. The input parameters represent, respectively, an upper timelimit for the analysis execution time, the source code and the criterion according to which thecode should analysed. The timer component is not shown in thefigure, because it behaves anexternal interrupt that merely controls the processing time. The output represents the analysis

13

result expressed in XML format.

ANSI C to XML

Tranformationto core language

Dependency Analyser

XML to Prolog Term

Source code (C)

Abstract SyntaxTree (XML)

DependencyAnalysis (XML)

DependencyCriteria (XML)

Program as anSGML term

XML to Prolog Term SGML term to XML

Criteria as anSGML term

Dependency analysis as an SGML term

Program as anSGML term

Variable Dependency Analyser

Fig. 7. V system architecture

Figure8 shows the modules of the system and their dependencies. In this figure, an arrow de-notes module dependency. An arrow from moduleA to moduleB means thatA is dependent onB, or, in other words, it uses the predicates of moduleB for its implementation. Prolog modulesare used withusemoduledeclarations which import public predicates of the modulesinto theimported program. The modulesvadaXTimer andvadaCTimer provide the command-line in-terface for the stand-alone V system. Both modules provide a predicatevadaTimer expectingfour parameters.

The modules can be classified into the following categories:User interface User interface modules implement the SWI-Prolog mechanism for building pro-

gram executables defining the program entry point. This is achieved byvadaXTimer andvadaCTimer. These modules allow the user to start V given the appropriate input pa-rameters. For the output, there are modules which transformtemporary/final results of corelanguage transformation or analysis from internal Prolog representation into XML format andsave them. The modulesfileutils andppsgml provide predicates for writing and savinganalysis results in XML format. More on the user interface inthe following section3.4.

Parser interface Interface to the SWI-Parser is needed for loading and parsingthe AST rep-resentation of the source code and the criterion delivered as XML files into Prolog SGMLstructures. This is realised throughutils.

14

Transformation Transforming the XML-encoded AST representation of the source code to-gether with the criterion into the core language. This is achieved bytrans.

Analysis Analysing the transformed code for variable dependencies.This is realised throughslice, defined andused.

Control flow Controlling the program flow between various modules. This task is taken byglue. Theglue module plays the role of a bridge between transformation, analysis, loadingand parsing files as Prolog SGML terms, modules receiving user input and those generatingoutput analysis. Most of the V modules are used byglue. The predicates of these mod-ules are called to load the AST representation of the source file and the criterion, to performtransformation and analysis and to deliver the results of the variable dependence analysis inthe (fourth) output parameter file in XML format.

Configuration The moduleoptions is used to set global configuration parameters.Debugging Modules developed for interactive use with the SWI-Prolog environment and meant

to serve development and debugging purposes. These modulesare not shown in Figure8.

3.3. Variable Dependence Relationships

In addition to calculating the set of dependent variables according to specified criteria definedlocally in terms of variables at a program point, V also computes global dependency propertiesamong all program variables and formal parameters of any function selected for analysis, or forthe entire program.

All program variables, including global variables, local variables and formal parameters aredivided into five different variable dependency sets or relationships. These relationships are:used, defined, definitely defined, needed, and controlling. In the following, the Control FlowGraph (CFG) program representation is used to define the variable dependency relationships.Used A set of used variables is one whose elements may be referenced before or after a variable

is assigned along some paths of the CFG from start node to the stop node.Defined A set of defined variables is one whose elements occur on the left-had side of an as-

signment node. Such variables are sometimes called “possibly defined” or “possibly assigned”,because they are not assigned on every path of the CFG from start node to the stop node.

Definitely defined A set of definitely defined variables is one whose elements areassigned (ap-pear on the left-hand side of an assignment node) on every path of the CFG from start node tothe stop node.

Needed A set of needed variables (for a variablev) is one whose elements’ initial values poten-tially affect the final value of the variable they are needed for (i.e.,v) along some paths of theCFG.

Controlling A set of controlling variables is one whose elements are needed for some variablev andv appears in a predicate node.

There are inclusion relationships between the variable sets just defined. Ifuseddenotes the set ofused variables,definedthe set of defined variables,neededthe set of needed variables,defineddefthe set of definitely defined variables andcontrolling the set of controlling variables, we notethat,

15

produce_xml_file/2

produce_c_file/2

form_full_file_names/3

xmlstream_to_term/1

save_xmlterm/2

<<«fileutils»>>

loadXMLfile/2

debug_print/1

...

<<«utils»>>

slice/7

slice_criteria/1

slice_in_statementblock/9

...

<<«slice»>>

debug_printing/1

path_to_ansic/1

path_to_xml/1

...

<<«options»>>

do_transform_no_criterion/2/

do_tran.._with_crit.._list/3

...

<<«trans»>>

Provides toplevel VADA predicates

vadaTimer/4

<<«vadaXTimer»>>Toegther with vadaCTimer, vadaXTimer represents

a wrapper for the stand-alone version

vadaX/3

vadaC/3

<<«glue»>>

usedForFunction/2

...

<<«used»>>

definedForFunction/4

...

<<«defined»>>

vadaTimer/4

<<«vadaCTimer»>>

<<«Prolog SGML/XML Parser»>>

laods XML file and call

Parser to get SGML term

representation

Transforms internal representation

of source code AST and criterion

into core language

pp_sgmlterm/1

<<«ppsgml»>>

Placeholder for global configurations

Together with <<defined>> &<<used>>,

slice performs variable dependence analysis

using slicing techniques

create_struct_table/4,

lookUpStruct/3,

member_struct_var_table/2

...

<<«structable»>>

Helper module for dealing with

struct and array variables

Fig. 8. Vmodules

16

Parameter Description

Timer constraintNumber setting an upper bound for processing time

Program Code File containing XML-encoded AST representation of the source code

Analysis criteriaFile containing analysis criteria in XML format

Analysis resultsName of file in which analysis results are saved

Fig. 9. Parameters of the V stand-alone system

defineddef ⊆ defined

controlling⊆ used

defined− defineddef ⊆ needed

needed− (defined− defineddef) ⊆ used

Next, we give some explanation examples on the variable dependence relationships as com-puted by V.

(i) For an assignment statement of the form:x=y+z;,the variablex is definitely definedand consequently alsodefined. The variablesy andz areusedandneeded.

(ii) For anif-statement of the form:if (p>q);,the variablesp andq arecontrollingand consequentlyusedbut neitherneedednordefined.

(iii) For anif-else-statement of the form:if (p>q) x=1; else {y=1; x=2;},the variablex is definitely definedand consequentlydefined. The variabley is definedandneeded. The variablesp andq areneeded, controllingand consequentlyused.

(iv) For a sequence of program statements of the form:x=1; y=1; if (x>y) z=y;,the variablesx andy aredefinitely definedand consequentlydefined. The variablez isdefinedandneeded.

(v) For anif-statement of the form:if (p>q) z=1;,the variablesp andq arecontrolling and consequentlyused, andneeded. The variablezis definedandneededbut notused. z is neededin order to define the final value of itself,since it may remain unchanged.

The last example illustrates whyneeded* used.

3.4. The User Interface

In this section the user interface which encompassesvadaXTimer andvadaCTimer is de-scribed in details. The difference between these modules lies in the representation of the programsubmitted for analysis. ThevadaXTimer predicate expects an XML-encoded AST representa-tion whereas thevadaCTimer predicate the source code itself. Internally, V transforms thesource code into XML-encoded AST representation before proceeding with the analysis. Thestand-alone V system expects four parameters shown in Figure9. In this figure, the entries inthe first column refer to the roles of the parameters, followed by brief descriptions.

V uses SWI-Prolog’s capability of handling software interrupts (signals) for implement-ing the timer functionality. Special cases arise from setting the timer parameter. A zero (integer)value switches the timer off; for any other positive value the timer demon is on. In cases wherethe parameter value is non-zero but less than the time required for completing the analysis, pro-

17

cessing the code is stopped without producing final results.In cases where the timer is off, Vstops processing the code only after the final result is readyand saved in a file named throughthe fourth parameter.

The second parameter specifies the file of the code to be analysed. The XML-encoded ASTrepresentation used internally by V is generated by a proprietary parser licensed to Daimler-Chrysler.

The third parameter specifies the analysis criteria. In thisfile all the functions of a programand all, or a subset of their statements can be specified as part of the analysis criteria. The XMLstructure of the criteria is shown in Figure10. A DTD file is not required. For functions, thereis afunction-tag with aname attribute and the statements to be analysed are specified as chil-dren. In Figure10, the function names are set arbitrarily. The values of theexpression-tagattributesexprref refer to statements as they appear in the XML-encoded AST representationof the source code. Again, the expressions used to representthe attributes’ values reflect thevalues’ structure, where repetitive sequences of letters such annn denote natural numbers. Forexample, if branch coverage for a certain function is required, theexprref entries correspondto all conditional and loop statements that appear in the code of the function.

V requires a criterion file before the analysis process can start. It is not required that allthe functions or their statements be specified. However, at least one function must be named.Figure11 shows the simplest criteria possible where only a function namedfoo is specified.Here,foo is assumed to be part of the program to be analysed. If the given name does not matchany of the program functions, V reports an error informing the user that the function has notbeen found.

A regular dependency criteria is always defined with respectto a program function. The fivedependency relationships of Section3.3are always computed for every program function spec-ified in the criterion. Program functions can also be selected without mention of any specificvariables and expressions (program points), in which case only the dependency relationships arecomputed for the selected functions.

If all four parameters are correctly given and the timer value is sufficiently long or set to (in-teger) zero, V generates an analysis output and saves the results in the filewhose name isspecified by the fourth parameter. In this result, variablesdependency relationships of all thefunctions specified in the analysis criteria are listed. V extends the set of variable dependencyrelationships includingDefinedandUsedby adding three more relationships:Definitely defined,NeededandControlling). In Section?? these relationships are defined and discussed in more de-tail. In addition, variables’ dependencies of statements specified in the criteria are also listed. Ifno statements are specified, only dependency relationshipsof all the variables of specified func-tions are listed. Figure12depicts the XML structure of the analysis results. The figureshows thatV, in addition to input variables, also includes local variables in the list attaching alocal nto these variables as prefix. Here,n denotes a number. Avariable-tag has two attributes speci-fying its name and itsidref as it appears in the XML-encoded AST representation of the sourcecode.

4. Empirical Study

The V system is designed to support the DC Evolutionary Testing System,which is a test data generation system for unit level testing. Therefore the system will only haveto scale to the size of a typical unit. This means that a computation that takes a few minutes,

18

<vdc>

<function name="f0-name">

<expression exprref="expr-nnn>"/>

<expression exprref="expr-mmm>"/>

...

<expression exprref="expr-lll>"/>

</function>

...

<function name="fn-name">

<expression exprref="expr-kkk>"/>

<expression exprref="expr-jjj>"/>

...

<expression exprref="expr-iii>"/>

</function>

</vdc>

Fig. 10. XML structure of the analysis criteria

<vdc>

<function name="foo" />

</vdc>

Fig. 11. Analysis criteria of the function “foo”

or even more, will be acceptable when there is a reduction in the size of the search space ofinput variables. Since not all predicates of all programs will depend upon all input variables,the computational effort required by V will almost certainly be considered worthwhile. Anempirical study by Binkley and Harman [4] revealed that predicates do not depend on all formalparameters and also that as the number of formals increases,the portion on which a typicalpredicate depends decreases.

4.1. Performance and Memoisation

The algorithmic complexity of the transformation phase is essentially linear because it involvesseveral passes through the program, each of which is linear.As previously observed, the worstcase for unfolding is exponential, but only in the depth of the call tree that grows logarithmicallywith program size and typically has a low value for unit levelcode.

The complexity of the slicing and variable dependence analysis phase can vary dramatically,from linear in the best case to (potentially) exponential inthe worst case. The worst case containsa sequence of loop carried dependencies (or ‘backward assignment’) in which each variable isassigned a value that depends upon the assignment that immediately follows it in the lexical orderof the loop body. In the worst case, this ‘backward assignment’ is nested within a chain of nestedloops, each of which contains killing assignments to the variables in the innermost loop and to theloop control variables. For such a program, the number of criteria that need to be considered by

19

<vdc>

<function name="f-name">

<defined>

<variable name="var-name" idref="id-nnn" />

<variable name="local n-var-name" idref="id-mmm" />

....

</defined>

<needed>

<variable name="var-name" idref="id-lll" />

...

</needed>

<controlling> ... </controlling>

<used> ... </used>

<definitely-defined> ... </definitely-defined>

<expression exprref="expr-kkk">

<vda> <variable name="var-name" idref="id-jjj" /> </vda>

</expression>

<expression exprref="expr-iii">

<vda>

<variable name="var-name" idref="id-uuu" />

<variable name="var-name" idref="id-vvv" />

</vda>

</expression>

</function>

...

<function name="g-name">

<defined> ... </defined>

<needed> ... </needed>

<controlling> ... </controlling>

<used> ... </used>

<definitely-defined> ... </definitely-defined>

...

</function>

</vdc>

Fig. 12. XML structure of V’s analysis results

the innermost loop is exponential in the number of program variables (though not in the programsize).

20

Clearly, such a highly artificial construction as the ‘worstcase’ program is unlikely to bepresented to V for analysis. However, the existence of such a program presents an upperbound on performance time and forms the basis for empirical evaluation of the performance ofthe system.

This analysis revealed that the performance could potentially be unacceptably slow, so a mem-oisation feature is added to the variable dependence analysis phase. That is, a data structure ofpreviously encountered slicing criteria is maintained forwhile loops. Where a criteria has pre-viously been met, there is no point in re-computing the dependence. This creates a saving incomputation time at the expense of memory space to record previously encountered criteria.However, it appears that the extra memory used by memoisation is more than offset by the re-duction in call stack usage, as the memoisation reduces the average depth of recursion in thealgorithm.

Memoisation is very applicable as a performance enhancement technique because criteria arerepeatedly re-encountered during the fixed point computation for loops. The memoisation algo-rithm used by V is not merely a case of recording previously encountered criteria in order toreuse them later. The algorithm exploits several useful properties of variable dependence. Vari-able dependence is monotonic. That is, if Vada(S,V) denotes the set of variables whose initialvalues are determined by the set of variablesV in the programS, then

U ⊆ V ⇒ Vada(S,U) ⊆ Vada(S,V)

This means that if awhile loop is to be analysed with respect to a set of variablesV, but alarger set has already been encountered in a previous computation, then the result of the previouscomputation can be used. Furthermore, variable dependenceis distributive

Vada(S,V ∪ U) = Vada(S,V) ∪ Vada(S,U)

This means that the results from several previous computations on subsets can be composed toform a partial answer to a current variable dependence question. These observations of mono-tonicity and distributivity are often used to improve performance of variable dependence usingmonotone dataflow analysis frameworks [1]. Similar memoisation techniques are also used byHarrold and Ci [19] to improve slicing using dataflow based algorithms.

A memoisation algorithm was implemented that exploits monotonicity and distributivity ofvariable dependence and we obtained a significant improvement in worst case performance. Anempirical study of performance improvement is presented innext subsection.

4.2. Results

Timings taken on a AMD 1GHz based PC running Linux 2.4.8 with amemory bandwidth ofcirca 147MB/s (as measured byhdparm). Measurements were taken by averaging the sum of theuser and system CPU time, as measured by the GNUtime program, over three runs for each testcase.

Figure13 shows execution times for different numbers of worst-case backward assignmentswithin five nestedwhile loops, with and without memoisation.

Figure 14 shows execution times for different depths ofwhile-loop nesting containing 50worst-case backward assignments, with and without memoisation. The maximum depth of nest-ing that could be analysed without memoisation was restricted by memory constraints. In partic-ular, the 32 bit architecture of the test machine imposed a maximum stack limit of 128MB (with

21

SWI-Prolog) that was exhausted with depths of six or more (tenor more with fewer backwardassignments).

Figure15 shows the execution times for forward assignments with no loops, where there isdependency on every assignment. There is no meaningful difference in the timings for the orig-inal and memoised versions of the system because the code that is responsible for managingmemoisation is only invoked when analysing loops.

original

memoised

0 50 100 150 200 250

0

50

100

150

Number of Backward Assignments

Exec

uti

onti

me

(sec

onds)

Fig. 13. Timings for worst-case backward assignments within five nestedwhile loops (timings without memoisation areshown by a dashed line)

original

memoised

0 5 10 15

0

50

100

150

Depth of Nested Loops

Exec

uti

onti

me

(sec

onds)

Fig. 14. Timings forwhile loop nesting with 50 worst-case backward assignments (timings without memoisation areshown by a dashed line)

22

originalmemoised

0 200 400 600 800 1000

0.2

0.4

0.6

0.8

1

1.2

Number of Assignments

Exec

uti

onti

me

(sec

onds)

Fig. 15. Timings for forward assignments with no loops (timingswithout memoisation are shown by a dashed line)

5. Related Work

The problem of variable dependence is closely related to program slicing [12,18,32] and chop-ping [21] because it involves the traversal of transitive data and control dependence relations. Inour implementation, the variable dependences for a programthat is expressed in the whole lan-guage are computed by way of a slicing algorithm that operates on the program following itstransformation into the core language.

Danicic [8] showed that slicing and variable dependence are related: aslice can be computedfrom a variable dependence relation by a suitable instrumentation of the source program to besliced. The instrumentation involves inclusion of an additional referenced variable in each ex-pression. This is a unique variable,v, which occurs nowhere else in the program. Therefore, ifv is included in the variable dependence for some variablev′ then the expression tagged byvis a member of the slice onv′. The identification of expressions (both arithmetic and boolean)required in a slice is sufficient to determine the slice itself. That is, the nodes of theProgramDependence Graph (PDG) [26] typically denote expressions (either the boolean expressions ofconditional statements or the arithmetic expressions of assignments).

Whereby program transformations are expected to preserve some form of functional equiva-lence [2,3,11,27,29,31], transformations proposed in this work are not meaning preserving in thetraditional sense. Although non-meaning preserving transformations have been considered forprogram modification in corrective and adaptive maintenance [13,14], the use of non-meaningpreserving transformation here appears to be novel. That is, for the purpose of producing the corelanguage from the C language, it is only necessary to preserve sufficient aspects of the behaviourof the program to ensure that the variable dependence relation remains invariant throughout thetransformation.

The semantic transformation of Section2.2 that accompany the syntactic transformation intothe core language defines an abstract interpretation [6,7] with an abstract domain which preservesthe property of variable dependence. Here, the concrete semantic domain is approximated atthe expense of simplifying the variable dependence analysis. This is similar to a non-relationalinterval domain where the interval analysis is simplified and thus made fast by overlooking the

23

relationships between variables (e.g. equality). The abstract interpretation is consistent with theconcrete semantics of the original program in maintaining variable dependency since controlflow is preserved in the transformation.

6. Conclusion

The V system computes variable dependence for the C programming language. The Vsystem adopts the approach of transforming the full C language to a more manageable core lan-guage, for which variable dependence is computed. A memoisation approach is used to improvethe efficiency of the analysis phase and initial empirical results on the speed-up it produces havebeen presented.

A novel aspect of these transformations is that they are not meaning preserving. At least, theydo not preserve the traditional functional equivalence relation that has remained thesine quanonof work on source-to-source transformation since the 1970s[10]. The V transformationengine need only preserve the variable dependence relationof a program.

The paper describes the transformation algorithm and formalises the analysis algorithm, show-ing how it has a natural expression in Prolog pseudo code. Thepaper describes an implementationof this approach and evaluates the performance improvementdue to memoisation.

References

[1] Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, techniques and tools. Addison Wesley,1986.

[2] Ira D. Baxter. Transformation systems: Domain-oriented component and implementation knowledge. InProceedings of the Ninth Workshop on Institutionalizing Software Reuse, Austin, TX, USA, January 1999.

[3] Keith H. Bennett. Do program transformations help reverse engineering? InIEEE International Conferenceon Software Maintenance (ICSM’98), pages 247–254, Los Alamitos, California, USA, November 1998. IEEEComputer Society Press.

[4] D. Binkley and M. Harman. An Empirical Study of Predicate Dependence Levels and Trends. InProceedings ofthe International Conference on Software Engineering (ICSE2003), Portland, Oregon USA, pages 330–340, 2003.

[5] David Wendell Binkley and Mark Harman. Analysis and visualization of predicate dependence on formalparameters and global variables.IEEE Transactions on Software Engineering, 30(11):715–735, 2004.

[6] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analysis of programs byconstruction or approximation of fixpoints. InConference Record of the Fourth Annual ACM SIGPLAN-SIGACTSymposium on Principles of Programming Languages, pages 238–252, Los Angeles, California, 1977. ACM Press,New York, NY.

[7] P. Cousot and R. Cousot. Systematic design of program analysis frameworks. InConference Record of theSixth Annual ACM SIGPLAN-SIGACT Symposium on Principles ofProgramming Languages, pages 269–282, SanAntonio, Texas, 1979. ACM Press, New York, NY.

[8] Sebastian Danicic.Dataflow Minimal Slicing. PhD thesis, University of North London, UK, School of Informatics,April 1999.

[9] Sebastian Danicic, Mark Harman, and Yogasundary Sivagurunathan. A parallel algorithm for static program slicing.Information Processing Letters, 56(6):307–313, December 1995.

[10] John Darlington and Rod M. Burstall. A system which automatically improves programs.Acta Informatica, 6:41–60, 1976.

[11] John Darlington and Rod M. Burstall. A tranformation system for developing recursive programs.Journal of theACM, 24(1):44–67, 1977.

[12] Andrea De Lucia. Program slicing: Methods and applications. In 1st IEEE International Workshop on Source CodeAnalysis and Manipulation, pages 142–149, Los Alamitos, California, USA, 2001. IEEE Computer Society Press.

24

[13] Nachum Dershowitz and Zohar Manna. The evolution of programs: A system for automatic program modification.In Conference Record of the Fourth Annual Symposium on Principles of Programming Languages, pages 144–154.ACM SIGACT and SIGPLAN, ACM Press, 1977.

[14] Martin S. Feather. A system for assisting program transformation.ACM Transactions on Programming Languagesand Systems, 4(1):1–20, January 1982.

[15] Roger Ferguson and Bogdan Korel. The chaining approachfor software test data generation.ACM Transactions onSoftware Engineering and Methodology, 5(1):63–86, January 1996.

[16] M. Harman, C. Fox, R. Hierons, L. Hu, S. Danicic, and J. Wegener. VADA: A Transformation-based System forVariable Dependence Analysis. InProceedings of the2nd IEEE International Workshop on Source Code Analysisand Manipulation (SCAM2002), Montreal, Canada, pages 55–64, 2002.

[17] Mark Harman, Youssef Hassoun, Kiran Lakhotia, Philip McMinn, and Joachim Wegener. The impact of inputdomain reduction on search-based test data generation. InACM Symposium on the Foundations of SoftwareEngineering (FSE ’07), pages 155–164, Dubrovnik, Croatia, September 2007. Association for Computer Machinery.

[18] Mark Harman and Robert Mark Hierons. An overview of program slicing.Software Focus, 2(3):85–92, 2001.[19] Mary Jean Harrold and Ning Ci. Reuse-driven interprocedural slicing. InProceedings of the 20th International

Conference on Software Engineering, pages 74–83. IEEE Computer Society Press, April 1998.[20] Susan Horwitz, Thomas Reps, and David Wendell Binkley. Interprocedural slicing using dependence graphs.ACM

Transactions on Programming Languages and Systems, 12(1):26–61, 1990.[21] Daniel Jackson and Eugene J. Rollins. Chopping: A generalisation of slicing. Technical Report CMU-CS-94-169,

School of Computer Science, Carnegie Mellon University, Pittsburgh, PA, July 1994.[22] Daniel Jackson and Eugene J. Rollins. A new model of program dependences for reverse engineering. In

Proceedings of the ACM SIGSOFT ’94 Symposium on the Foundations of Software Engineering, pages 2–10,December 1994.

[23] Arun Lakhotia. Rule–based approach to computing module cohesion. InProceedings of the15th Conference onSoftware Engineering (ICSE-15), pages 34–44, 1993.

[24] Peter J. Landin. The next 700 programming languages.Communications of the ACM, 9(3):157–166, March 1966.[25] Michael R. Laurence, Sebastian Danicic, Mark Harman, Rob Hierons, and John Howroyd. Equivalence of

conservative, free, linear program schemas is decidable.Theoretical Computer Science, 290:831–862, January2003.

[26] Karl J. Ottenstein and Linda M. Ottenstein. The programdependence graph in software development environments.Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software DevelopmentEnvironmt, SIGPLAN Notices, 19(5):177–184, 1984.

[27] Helmut Partsch.The CIP Transformation System, pages 305–322. Springer, 1984. Peter Pepper (ed.).[28] Joseph E. Stoy.Denotational semantics: The Scott–Strachey approach to programming language theory. MIT

Press, 1985. Third edition.[29] Martin Ward. Reverse engineering through formal transformation.The Computer Journal, 37(5), 1994.[30] Martin Ward. The formal approach to source code analysisand manipulation. In 1st IEEE International Workshop

on Source Code Analysis and Manipulation, pages 185–193, Los Alamitos, California, USA, 2001. IEEE ComputerSociety Press.

[31] Martin Ward, Frank W. Calliss, and Malcolm Munro. The maintainer’s assistant. InProceedings of the InternationalConference on Software Maintenance 1989, page 307, Los Alamitos, California, USA, 1989. IEEE ComputerSociety Press.

[32] Mark Weiser. Program slicing.IEEE Transactions on Software Engineering, 10(4):352–357, 1984.[33] Elaine J. Weyuker.Program schemas with semantic restrictions. PhD thesis, Rutgers University, New Brunswick,

New Jersey, June 1977.

25