Interprocedural Control Dependence

James Ezick and Kiri Wagstaff

CS 612

May 4, 1999

2

Outline

• Motivation• Some essential terms• Constructing the interprocedural postdominance

relation• Answering interprocedural control dependence

queries• Future work

3

Motivation

• As we have seen in class the Roman Chariots formulation for intraprocedural control dependence (Pingali & Bilardi) has allowed control dependence queries to be answered in (optimal) time proportional to the output size.

• We seek to extend that work to cover control flow graphs representing multiple procedures without the need for fully cloning each function.

4

How would that make the world better?

• Recall that control dependence (conds) is the same as the edge dominance frontier relation of the reverse graph.

• Recall that the dominance frontier relation is used in the construction of SSA form representations.

• If we could build this representation faster it would allow us perform a wide range of code optimizations in a more uniform and more efficient manner.

5

Valid Paths - Context Sensitive Analysis

• Valid path: A path from START to END in which call and return edges occur in well-nested pairs and in which these pairs correspond to call sites and the return sites specific to these call sites.

START

a

b

c

d

F

END

This is intended to exactly capture ourintuition of a call stack.

6

Other Terms

• Node w interprocedurally postdominates v if every valid path from v to end contains w.

• Node w is ip control dependent on edge (u v) if– w ip postdominates v

– w does not strictly ip postdominate u

We notice immediately that these definitions are completely analogous to their intraprocedural counterparts - they however incorporate the notionof valid paths.

7

First postdominence, then the world!

As the definitions suggest there is a tight relationship between control dependence and postdominance.

To compute control dependence we first would like to compute postdominance subject to the following criteria:

• We minimize cloning to the fullest possible extent.• We are able to parallelize the process. (One

function - one thread).• We can deal with all common code constructs

(including recursion).

8

Computing Postdominance

• In the intraprocedural case every path through the control flow graph is a valid path and the resulting postdominance relation is a tree.

• Algorithms exist to produce this tree which run in time linear in the size of the control flow graph (Rodgers, et al.).

• The introduction of non-valid paths into the CFG breaks this property - the transitive reduction is now a DAG.

9

How is this done today?

• We use iterative methods and context sensitive flow analysis to compute postdominance and control dependence.

• This involves keeping a table of inputs and outputs.

• Convergence occurs due to the finite nature of the table but it is not guaranteed to occur quickly.

10

General Description

• First, we do a generalized form of dataflow analysis in which each procedure acts as a single block box transition function.

• By keeping a table of inputs and outputs of this function for each procedure we gain efficiency and can detect termination.

• After the interprocedural relationships are understood - we compute the intraprocedural info for each procedure in the usual way.

11

Where we break down

Start

End

F-start

F-a

F-end

G-start

G-a

G-end

A

B C

D E

H I

J K

L

Call F

Call G

Call G

Call F

Ret G

Ret FRet G

Ret F

End

StartL

J K

H

G-start

G-a

G-end F-end

F-a

F-start

I

D E

B C

A

Notice the existence of an invalid path:Start-A-B-(F-Start)-(F-a)-(F-end)-K-L-End

Control Flow Graph Postdominance DAG

12

So What?

• We could ignore the invalid paths and claim that we are being “conservative”.

• However, if we do this we lose the fact that A is postdominated by both F and G - this is vital information that we can’t sacrifice and still expect to be able to compute control dependence.

• We need to construct this DAG in its full form.

13

Observations

• We notice that the postdominance relations for F and G are subgraphs of the entire postdominance relation.

• This begs the question - Can we simply compute the postdominance relation with place-holders for F and G and then simply splice the F and G graphs in later?

• What information would we need to do this?

14

First Attempt

• Is it enough to simply know the two nodes that “bookend” all the calls to a specific function?

Start

End

Call F

Ret F

Call F

Ret F

A

B C

D

E G

H I

Start

End

A

D

B C

E

H

Call FG

I Ret F

Call F

Ret F

End

StartD

B C I

G

H

E

A

We notice that these two distinct control flow graphs produce the same postdominance DAG minus the presence of the F subgraph. Further, [A,D] bookends the calls to F in each case.

15

Defeat!

• Clearly, this technique fails to capture the fact that in the first case the F subgraph should postdominate both B and C whereas in the second case it should not.

• Conclusion: we need to know more than which link to break - we need to know what to do with the ancestors of the destination.

16

Correct Solutions after Splicing

StartD

B C I

G

H

E

F

A

StartD

C

I

G

H

E

F

A

B

Case I Case II

We need more information than which connection to break to accurately do this splice.

EndEnd

17

What do we need to know?

• We can think of a tree or a DAG as a representation of a partial order. Specifically we can think of the postdominance relation as a partial order since it is reflexive, anti-symmetric and transitive.

• Given this insight, we see that we need to inject the F subgraph into the partial order. Simply knowing two bounds is not enough to do this.

18

It gets worse

• In the example provided we only needed to place B & C - singleton ancestors of D. In fact we can build CFGs where we have arbitrarily complex subgraphs feeding into D.

D

A

FWe want to “splice” F in between D and A.

UVW

X

Y

Z

19

• In order to inject F into the partial order we must also inject F into every path from a terminal to D.

100,100

0,0

F

40,7560,60

70,7050,80

90,90

65,45

We define the partial order as := (a,b) < (c,d) iff (a<c) and (b<d).

100,100

0,0

F

40,7560,60

70,7050,80

90,90

65,45

100,100

0,0

F

40,7560,60

70,70

50,80

90,90

65,45

95,5 95,9572,78

Furthermore, determining where to break each path requires a sequence of UPD queries.

20

Union Postdominance

• We say that a set T union postdominates a set S in an interprocedural control flow graph if every valid path from an element of S to end contains an element of T.

• In the preceding case we must determine for each element of the subtree if it is union postdominated by all of the calls to a specific function.

• This is clearly not promising.• This extends Generalized Dominators (Gupta 92).

21

OK, so we do that - what then?

• Our problems do not end there - consider the following CFG.

Start

End

B C

DE

I

Call F

Ret F

Call G

Ret G

Call H

Ret H

F-Start

F-End

F-A

F-B Call H

Ret H

G-Start

G-End

H-Start

H-End

H-A

Control Flow Graph for Main Control Flow Graph for F Control Flow Graph for G Control Flow Graph for H

G-A

G-C

G-D

G-E

G-B

22

• When we splice in and expand the graphs for F and G we get two copies of H!

H

H

End

Start

E

F-End

F-B

F-A

F-Start

CB

G-C

G-Start

G-D

G-E

G-B

G-End

D

A

I

Maybe this isn’t so bad - can’t we just “merge” them somehow?

G-A

23

Oh, it’s bad.

• Given the partial postdominance relation all I can recover from it about H is that H should be a child of I.

• I don’t know which link from I to break; also I again don’t know what to do with the other children of I.

• As with the previous case I can create CFGs that make this arbitrarily complicated. Further I must now do UPD queries over the entire CFG.

24

Plan “A” is a loser

• It is clear that we cannot simply compute these function DAGs independently and then splice them together since the splicing is more expensive than the original computation.

• We need to find a way to incorporate the splicing information into the original computation.

• In essence we need subgraph “placeholders” for each function.

25

A New Hope

• It is clear that in order to construct the postdominator relation componentwise we need more a priori information.

• In essence we need to understand all of the possible call sequences a program segment can initiate - then we let transitivity do the rest.

• To that end we introduce the notion of “sparse stubs”.

26

Sparse Stubs

• Given a program for which we want to construct a control flow graph we construct a sparse representation in parallel that captures only calls and branches.

• We then use this sparse representation as a “stub” which we inject into the gap between a call and return.

• This stub then captures what we need to construct a PDD into which we can inject full subgraphs.

27

An Example

HH

Start

End

F-Start

F-End

G-Start

G-End

Sparse Representation

Notice that this captures every possible sequence of calls in the program (starts and ends).

Since H is a “terminal function” we can represent it as a singleton. F, G (which are not terminal) cannot be represented this way - else we could not distinguish between “F calls H” and “call F then H”.

We can employ similar shortcuts to eliminate “repeated suffixes” (ex. “call F, call G, call F”)In the case of recursion the sparse graph will have a loop from the call back to the start node of the function - but that’s fine.

28

That’s great. What now?

• We notice immediately some interesting properties of this sparse graph. First any function that is called multiple times will have multiple representations in this graph - but they are all the same. Build them once and use pointers.

• If we inject into the “call gap” of a function the subgraph of the sparse representation between start and end we get a “plug” for the gap.

29

What about this plug?

• We notice that the plug captures exactly all of the valid paths of the program.

• Further, it contains enough information to produce in the resulting PDD placeholders for the component functions.

• The price of this good fortune is that we now have duplicate nodes in the control flow graph (these however are all start & end nodes).

30

Union Postdominance

• We now have a purely graph theoretic problem for which we need (have?) a good algorithm.

• Given a directed graph with a source and sink and a partition of the nodes P - construct the PDD consisting of the elements of the partition.

• We have a naïve quadratic algorithm to do this but we are looking at existing algorithms with better performance that solve similar problems.

31

Can’t we just see an example?

HH

Start

End

F-Start

F-End

G-Start

G-End

Sparse Representation

Start

End

B C

DE

I

Call F

Ret F

Call G

Ret G+ =

Control Flow Graph for Main

Start

End

B C

DE

I

H

F-Start

F-End

H

G-Start

G-End

CFG ready for UPD AlgorithmIn this case the partition P is the set of singletonswith the two H nodes in a single set.

32

Produce the UPDD for each function

Start

End

B C

DE

I

H

F-Start

F-End

H

G-Start

G-End

H

Notice that this is a tree - there are no invalid paths!

End

Start

B C

G-Start

G-End

F-Start

F-End

A

I

ED

H appears in this graph only once - in exactly the correct location!

UPD Algorithm

Given this UPDD and the other UPDDs for F, G & H we use the starts and ends as placeholders to splice them in.In essence, we “pattern match” to construct the full UPDD. (In practice - use pointers.)

33

Final Observations

• We notice that the only cloning which has occurred related to the functions called - not their functionality

• Once the sparse stub graph is constructed the individual UPDD can be constructed independently.

• Using pointers - splicing is now constant time.• We can deal with recursion and cyclic calls.

34

Control Dependence

• Node w is control dependent on edge (u v) if– w postdominates v

– w does not strictly postdominate u

Control Flow Graph Postdominator Tree

START

a

b

c e

d END

END

d

e

c

b

a

START

a b c d e

Control Dependence Relation

START a

b c

35

Queries on Control Dependence

• cd(e): set of nodes control dependent on edge e

• conds(v): set of edges v is control dependent on

• cdequiv(v): set of nodes with same control dependencies as node v

a b c d e

Control Dependence Relation

START a

b c

36

Roman Chariots: cd(e)• Represent cd(e) as an interval on the pdom tree• cd(u v) = [v, END] - [u, END] = [v, parent(u))

– cd(START a) = [a, END)– cd(b c) = [c, e)

a b c d e

Control Dependence Relation

START a

b c

Postdominator Tree

END

d

e

c

b

a

START

a

37

Roman Chariots: conds(v)

• Record intervals at bottom endpoints

• Variable amounts of caching

No caching

END

d

e

c

b

a a

Full caching

END

d

e

c

b

a a{1}

STARTSTART

{2} {2}

{2}

{1}

{1,2}

{1}

{}

{}

Edge Interval

1 START a [a, END)

2 b c [c, e)

38

Vertex conds(v) Size Lo

a {1} 1 a

b {1,2} 2 b

e {1} 1 a

Roman Chariots: cdequiv(v)

• Compute fingerprints for conds sets– size of conds set

– lo(conds): lowest node contained in all intervals in conds set

• Two conds sets are equal iff fingerprints matchIntervals

1 START a [a, END)

2 b c [c, e)

39

The Interprocedural Case

• Postdominance relation is a DAG, not a tree

Control Flow Graph Postdominator DAG

START

a

b f

j

END

END

ge

j

fe

i

START

c

d

g

h

ie call F

call Gcall F

call Gh

g

f

a

gsfse

d

c

b

40

Interprocedural cd Queries

• cd(u v) = [v, END] - [u, END]

• Tree: linear interval

• DAG: many paths!

• No simple parent(v) trick (v may have multiple parents)

• In fact, we want an all-paths interpretation

• Roman Aqueducts!– u is a polluted source, v is a pure source

– Emperor: “Which cities still have clean water?”

41

Intervals on the DAG

• To compute cd(u v), need [v, END] - [u, END]• Break [v, END] into aqueducts (linear intervals)• For each aqueduct, is endpoint pollutable

(reachable) by u?• If so, replace endpoint with point where flows

from u and v merge (LCA(startpoint, u))– change interval to open instead of closed to ensure

exclusion of (polluted) LCA

• Then cd(u v) = union of (modified) aqueducts

42

Example: cd(a b)

cd(a b)

= [b,b] + [c,d] + [fs,fs) +

[e, j) +[gs,gs)

= {b,c,d,e}Postdominator DAG

END

ge

j

fe

i

START

h

g

f

a

gsfse

d

c

b

Aqueduct Reachablefrom a?

LCA(startpoint,a)

ModifiedAqueduct

[b, b] N - [b, b]

[c, d] N - [c, d]

[fs, END] Y fs [fs, fs)

[e, END] Y j [e, j)

[gs, END] Y gs [gs, gs)

43

Interprocedural conds Queries

• Emperor: “Which flows pass through a certain city?”

• Search all aqueduct systems for that city

• Faster: use variable caching

Postdominator DAG

END

ge

j

fe

i

START

h

g

f

a

gsfse

d

c

b

Edge Aqueduct System

1 START a {a,fs,fe,gs,ge,j}

2 a b {b,c,d,e}

3 a f {f,g,h,i}

44

Interprocedural cdequiv Queries

• Emperor: “I know that one city is polluted. What other cities are similarly affected?”

• Compare aqueduct systems for all cities for matches

• Faster: apply ‘fingerprint’ approach

45

Final Observations II

• We can compute intervals on the DAG (viewed as Roman Aqueducts)

• We have shown procedures for answering interprocedural control dependence queries

• We may be able to extend the faster methods from the Roman Chariots approach to the interprocedural case as well

46

In Conclusion ...

• We have demonstrated a foundation on which to build an interprocedural analysis capable of dealing with modern programming constructs without resorting to iteration or extensive cloning.

• What lies ahead is to prove this foundation correct and superior to existing techniques with more rigorous proofs and a working implementation.

• At this time we are very optimistic about this formulation.