Scribd
Upload
11 views

Code Optimization IV

The document discusses data flow analysis and data flow abstraction. It explains that data flow analysis abstracts program states by associating each program point with a data flow value representing possible states rather than tracking all states. This value is a set of definitions that can reach that point. The analysis uses transfer functions relating values before and after statements and control flow constraints. Reaching definitions is a common data flow schema that tracks which variable definitions can reach each point.

Uploaded by

Aakash D.V
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
11 views

Code Optimization IV

The document discusses data flow analysis and data flow abstraction. It explains that data flow analysis abstracts program states by associating each program point with a data flow value representing possible states rather than tracking all states. This value is a set of definitions that can reach that point. The analysis uses transfer functions relating values before and after statements and control flow constraints. Reaching definitions is a common data flow schema that tracks which variable definitions can reach each point.

Uploaded by

Aakash D.V
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Data-Flow Analysis - Data Flow Abstraction

● The position of the numbers in the


diagram is called program points
● shortest complete execution path
consists of the program points (1, 2,
3, 4, 9)
● Next shortest path (1, 2, 3, 4, 5, 6, 7,
8, 3, 4, 9)
● At program point (5), a=1 due to
definition d1 in Block B1
● d1 reaches point (5) in the rst
iteration.
● In subsequent iterations, d3 reaches
point (5) and the value of a is 243.
[email protected] 08/07/2023 41
Data Flow Abstraction

● Not possible to keep track of all


program states for all possible paths
● In data-flow-analysis, do not
distinguish among the paths taken
to reach a program point.
● Do not keep track of entire states;
● Rather, abstract out certain details,
keeping only the data for the
analysis purpose.
● May summarize all the program
states at point (5) by saying that the
value of a is one of (1; 243), defined
by one of(d1 ; d3)
[email protected] 08/07/2023 42
The Data-Flow Analysis Schema
● Associate with every program point a data-flow value that represents an
abstraction of the set of all possible program states
● The set of possible data-flow values is the domain for this application.
● Data-flow value is a set of definitions
● Each program points is associated with a set of definitions which can reach
that program points
● Data- flow values before and after each statement s is denoted by by IN[s]
and OUT[s]
● The data- flow problem is to find a solution to a set of constraints on the
IN[s]'s and OUT[s]'s, for all statements s.
● There are two sets of constraints - transfer functions and control flow
constraints.

[email protected] 08/07/2023 43
Transfer Functions Constraints
● The data- flow values before and after a statement are constrained by the
semantics of the statement.
● Suppose our statement of interest is y = x , and the value of x before this
statement is 2.
● So, after we execute the statement y=x, both the values of x, and y will be 2
● This relationship between the data- flow values before and after the
assignment statement is known as a transfer function.

[email protected] 08/07/2023 44
Transfer Functions Constraints
● Through transfer functions information can propagate either to the forward
along with execution path or backwards up the execution path
● In a forward- flow problem, the transfer function fs of a statement s, takes the
data- flow value before the statement and produces a new data- flow value
after the statement as follows:
○ OUT[s] = fs(IN[s])
● In a backward- flow problem, the transfer function fs for statement s converts
a data- flow value after the statement to a new data- flow value before the
statement as follows:
○ IN[s] = fs(OUT[s])

[email protected] 08/07/2023 45
Control-Flow Constraints
● Control Flow Constraints on data- flow values is derived from the flow of
control.
● Within a basic block, control flow is simple.
● If a block B consists of statements s1, s2, …., sn in that order, then the control-
flow value out of si is the same as the control- flow value into si+1 .
○ IN[si+1 ] = OUT[si ], for all i = 1, 2, ….,n-1
● Control- flow edges between basic blocks create more complex constraints

[email protected] 08/07/2023 46
Data-Flow Schemas on Basic Blocks
● Can restate the schema in terms of data- flow values entering and leaving the
blocks.
● Denote the data- flow values immediately before and immediately after each
basic block B by IN[B] and OUT[B], respectively.
● Suppose block B consists of statements s1,....., sn, in that order.
○ If s1 is the first statement of basic block B, then IN[B] = IN[s1],
○ If sn is the last statement of basic block B, then OUT[B] = OUT[sn]
● The transfer function fB of a basic block B , can be derived by composing the
transfer functions of the statements in the block.
● If fs be the transfer function of statement si then
○ fB = fsn ∘…..∘ fs2 ∘ fs1
○ OUT[B] = fB (IN[B])
[email protected] 08/07/2023 47
Data-Flow Schemas on Basic Blocks
● Constraints due to control flow between basic blocks can easily be rewritten
by substituting IN[B] and OUT[B] for IN[s1] and OUT[sn], respectively
● If data- flow values are information about the sets of constants that may be
assigned to a variable then the forward - flow problem is
○ IN[B] = ⋃P a predecessor of B OUT[P]
● In backwards-flow (details in live-variable analysis), the equations are similar,
but with the roles of the IN's and OUT's reversed.
○ IN[B] = fB (OUT[B])
○ OUT[B] = ⋃S a successor of BIN[S]

[email protected] 08/07/2023 48
Reaching Definitions
● One of the most common and useful data- flow schemas.
● When control in a program reaches a point p, knowing the location where
each variable x was defined provides many information about x
○ For instance, compiler then knows if x is a constant or not at point p, or
○ A debugger can tell whether it is possible for x to be an undefined
variable
● A definition d reaches a point p if there is a path from the point immediately
following d to p - and d is not killed along the path
● A definition of a variable x is killed if there is any other definition of x anywhere
along the path.
● If a definition d of of some variable x reaches a point p, the x might be defined
at location d
[email protected] 08/07/2023 49
Reaching Definitions: Example

● This flow graph has seven


definitions (d1, d2, ….,d7)
● Let’s consider our focus is
on Block B2.
● All the definitions in block
B1 reach the beginning of
block B2
● definition d5 : j = j-1 in
block B2 also reaches the
beginning of block B2
● However, this definition
kills the definition d2 : j = n
[email protected] 08/07/2023 50
Reaching Definitions: Example

● d4 : i = i+1 in B2 does not


reach the beginning of B2 as
in B4, d7: i=u3 kills d4
● d6 : a = u2 also reaches the
beginning of block B2

[email protected] 08/07/2023 51
Reaching Definitions: Drawbacks

● Example:
○ if (a == b) statement 1; else if (a == b) statement 2;
● For no values of a and b can the flow of control actually reach statement 2
● whether each path in a flow graph can be taken is an undecidable problem.
● it is conservative to assume that a definition can reach a point even if it
might not.
● Thus, we may allow paths that are never be traversed in any execution of
the program
● may allow definitions to pass through ambiguous definitions of the same
variable safely.

[email protected] 08/07/2023 52

You might also like