Data Flow Analyses From Succinct Analysis Specifications

Document Sample

```					   Data Flow Analyses from
Succinct Analysis Specifications.
The DFAGEN Tool

Andrew Stone,
Michelle Strout,
Shweta Behere (Avaya)
FRACTAL Conference
October 13

Slide 1
Why Data-Flow Analysis?
There are programs we’d like to
Automatically analyze -- but why???

Program Analysis is Useful because these
things are useful:
Optimization
Program Understanding
Debugging
DF-Analysis is a common way or formulating
flow- sensitive analyses

Slide 2
Why DF Analysis is Hard To Implement:

It’s easy to formulate DF analyses for
languages that only have scalars and no
pointers and function side effects.

Too bad that rules out most languages

Aggregates?!     Side Effects?!
Slide 3
Why DFAGen?

Aggregates?!           Side Effects?!

DFAGen automatically generates pointer, side-effect, and aggregate
Cognizant analyses from succinct, intuitive, specifications.

Slide 4
DFAGen Versus Hand-Written

Writes
OA DF Analysis
Writes             Framework                           .SPEC File

Passed to
C++
Generates
Source
Code                   C++          You write:
Source
Code
• 8 line SPEC file
You write:                                    DFAGen Writes:
• 376 lines                                   • 398 lines of C++ code
Slide 5
In Set
Example:
In Set: {s1, s2} Code: a = 6
{}
S1: a = 3
{S1}            Out Set
Reaching Defs                                            Transfer function for
{S1}
Transfer Function                 S2: b = c*d Locally, Separable, Analyses
OUT[n] = GEN[n] U (IN[n] – KILL[n])         {S1, S2}
Data-Flow Values
S1: a = 3                                 {S1, S2} Of some type (stmts)
GEN[n] S5
S2: b = c * =d
KILL[n] = S1
S3: if(cond):                               {S1, S2}
S4:          c = 5                        S3: if(cond)
{S1, S2}
else:
Out Set: {s2, s5}
S5:          a = 6
S6: print a;                 {S1, S2}
{S1, S2}                       {S1, S2}
{S1, S2}
S4:
S4: cc==55                       S5: aa==66
S5:
{S1,
{S1, S2, S4}
S2, S4}                       {S2,
{S2,S5}
S5}
U
{S1, S2, S4, S5}
{S1, S2, S4,S5}         Meet operator (union)
S6: print
S6: print aa
{S1, S2, S4, S5}
{S1, S2, S4, S5}
Slide 6
Other Things to Consider:
What direction should the analysis be performed in
(forwards or backwards)
Reaching Defs – forward
Liveness - Backwards

What sort of information is flowing from node to
node
Reaching Defs - Typically sets of Statements
Liveness – Sets of Variables

Is it a may or must analysis?
Liveness - May
Available Expressions - Must

Slide 7
Reaching Definitions Again
{}
S1: a = 3                        Meet: union
{S1}                          Direction: forward
Flowtype: statements
{S1}                          Style: may
GEN[s] =s | defs[ s ]  Ø
S2: b = c*d
{S1, S2}

{S1, S2}
KILL[s] =   t | defs[t ]  defs[s]
S3: if(cond)
{S1, S2}
reachingdefs.spec

{S1, S2}                          {S1, S2}    analysis: ReachingDefs
S4: c = 5                          S5: =
S5: a = 66     meet: union
{S1, S2, S4}                       {S2, S5}      direction: forward
flowtype: stmt
style: may

{S1, S2, S4, S5}                 gen[s]: { s | defs[s] !=empty }
S6: print a                     kill[s]: { t | defs[t] <= defs[s] }
{S1, S2, S4, S5}

Slide 8

Aggregates?!               Side Effects?!

reachingdefs.spec
analysis: ReachingDefs
meet: union
direction: forward
flowtype: stmt
style: may

gen[s]: { s | defs[s] !=empty }
kill[s]: { t | defs[t] <= defs[s] }

Slide 9
int x, y, z;
May or Must
int *p, *q;

x = rand() % 1000;     Must use: {x, y}
y = rand() % 1000;     May use: {x, y}
z = rand() % 1000;

p = &x;
q = &y;

if(*p < *q) {
q = &z;
Must def: {}
}                       May def: {y, z}
*q = 500;
Slide 10
Predefined Sets
Defs[s]: Set of variables that are defined at a statement
Uses[s]: Set of variables that are used at a statement
predefined: defs[s]
description: Set of variables defined given some statement.
argument:    stmt s
calculates: set of var, predefined, mStmt2MayDefMap,
mStmt2MustDefMap
maycode:
// C++ Code to calculate set of vars that may be defined
// Takes aliasing into account.
end
mustcode:
// C++ code to calculate set of vars that must be defined.
// Takes aliasing into acconut.
end

Slide 11
So is it May or Must?

reachingdefs.spec
analysis: ReachingDefs
meet: union
May
direction: forward
flowtype: stmt
style: may

gen[s]: { s | defs[s] !=empty }
kill[s]: { t | defs[t] <= defs[s] }
Must

Slide 12
How DFAGen Determines May/Must
Meet     Type      Gen     Kill
union    may      Upper Lower      • Parse GEN and KILL
intersect must Lower Upper          expressions into an AST.
Operator     UB     UB       LB      LB
• Analyze in a top down
lhs    rhs       lhs    rhs
fashion, determine whether
<=       lower   upper upper lower         we want an “upper bound” or
>=       upper lower lower upper           “lower bound” value at each
<       lower   upper upper lower         node.
>       upper lower lower upper
union     upper upper lower lower           • Use tables to left to
intersect upper upper lower lower             determine these values.
!=empty upper            -   lower        -

Slide 13
More Detail
gen[s]: { s | defs[s] !=empty }
kill[s]: { t | defs[t] <= defs[s] }

Meet        Type       Gen    Kill     Meet        Type           Gen        Kill
union
GEN        UB
reachingdefs.spec
may Upper Lower             union       may
KILL             LB
Upper Lower
analysis: ReachingDefs Upper intersect must Lower Upper
intersect must Lower
meet: union
May
Operator Build stmt UBLB
forward
direction: Set                         Build Set
flowtype:UB UB            LB
Operator   UB UB          LB LB
LB
style: may
lhs     rhs lhs    rhs     lhs       rhs   lhs rhs
<=
gen[s]: { s upper upper lower}
lower | defs[s] !=empty
!=empty
kill[s]: { t |
!=empty upper
defs[t]
-
UB    <=
<= defs[s] }
-
lower !=empty upper
lower
<=   Must
upper upper lower
-
LB
lower           -

Defs[s]        UB            defs[t]       UB                   defs[s]          LB
(may)
(may)                              (must)
Slide 14
Architecture of DFAGen
Specification
File                                         Code
Generation

AST
Analysis
C++ Files.
Scanner
May/Must
Analysis
tkn   tkn
tkn
AST

AST
Parser        AST
Environment           Type Inference
Analysis             and Checking

Slide 15
How This Work Will Be Evaluated

Evaluation in terms of Lines of Code
• LOC in handwritten analysis
• LOC in specification file
• LOC in predefined set code
• LOC in generated files

Evaluations in terms of speed
Time to perform a:
handwritten analysis versus a DFAGEN analysis.

Slide 16
Status
• What Works
– Liveness Analysis
– Reaching Definitions
• We also plan to add Available Expressions
• We have a hand written version of
reaching definitions we’ll use to compare
against.
• We plan to run evaluations against
SPEC2006 benchmarks.

Slide 17
Conclusions
DFAGen makes writing analyses easier.

It generates the analysis from
succinct specifications.

These specifications are written as if
aliasing and side-effects were non-
issues.

We hope to prove that DFAGEN
generated analyses are as fast a hand-
written equivalents.
Slide 18

```
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
 views: 31 posted: 11/23/2012 language: English pages: 18