Automated Soundness Proofs for Dataflow Analyses and Transformations via Local Rules

1
Automated Soundness Proofs for Dataflow Analyses
and Transformations via Local Rules
graduating this year!

• Sorin Lerner
• Todd Millstein
• Erika Rice
• Craig Chambers
• University of Washington
• UCLA

2
A traditional compiler
Compiler
Parser
Opt
Opt
Opt
Code Gen
3
Using a domain specific language
Compiler
Parser
DSL Opt
DSL Opt
DSL Opt
Code Gen
4
Using a domain specific language
Compiler
DSL Execution engine
Parser
Code Gen
DSL Opt
DSL Opt
DSL Opt
5
Checking correctness automatically
Compiler
DSL Execution engine
Parser
Code Gen
DSL Opt
DSL Opt
DSL Opt
6
Checking correctness automatically
Compiler
DSL Execution engine
Parser
Code Gen
7
Checking correctness automatically
Checker
8
Checking correctness automatically
DSL Opt
Checker
9
Checking correctness automatically
DSL Opt
10
Checking correctness automatically
DSL Opt
Checker
VCGen
Verification Condition (VC)
11
Checking correctness automatically
DSL Opt
Checker
VCGen
Verification Condition (VC)
12
Checking correctness automatically
Lemma VC implies correctness
Checker
VC
13
Cobalt
PLDI 03

• The Cobalt DSL is an instantiation of this
  architecture
• An opt written in Cobalt is a rewrite rule
  triggered by a declarative global condition over
  the CFG
• Expressed and automatically proved the
  correctness of a variety of intraprocedural
  optimizations, including
• const prop and folding, branch folding, CSE, PRE,
  DAE, partial DAE

14
In this talk the Rhodium DSL

• Increased expressiveness
• New model for expressing opts local propagation
  rules with explicit dataflow facts
• Heap summaries
• Infinite analysis domains
• Flow-sensitive and -insensitive
• Intraprocedural and interprocedural
• Some Rhodium opts not expressible in Cobalt
• Arithmetic invariant detection, integer range
  analysis, loop-induction-variable strength
  reduction, Andersen's may-point-to analysis with
  allocation-site summaries

15
Outline

• Overview
• Rhodium by example
• Checking correctness automatically
• Future work, related work and conclusion

16
MustPointTo analysis
a b
c a
c d
17
MustPointTo info in Rhodium
a b
c a
c d
18
MustPointTo info in Rhodium
a b
a b
c a
c a
c d
c d
19
MustPointTo info in Rhodium
define fact mustPointTo(XVar,YVar)
a b
c a
c d
20
Propagating facts
define fact mustPointTo(XVar,YVar)
a b
c a
c d
21
Propagating facts
define fact mustPointTo(XVar,YVar)
a b
a b
if currStmt X Y then mustPointTo(X,Y)_at_ou
t
if currStmt X Y then mustPointTo(X,Y)_at_ou
t
mustPointTo (a, b)
mustPointTo (a, b)
mustPointTo (c, d)
c a
c d
22
Propagating facts
define fact mustPointTo(XVar,YVar)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
c a
c d
23
Propagating facts
define fact mustPointTo(XVar,YVar)
mustPointTo (c, d)
mustPointTo (c, d)
a b
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
mustPointTo (a, b)
if mustPointTo(X,Y)_at_in Æ currStmt Z W
Æ X ? Z then mustPointTo(X,Y)_at_out
if mustPointTo(X,Y)_at_in Æ currStmt Z W
Æ X ? Z then mustPointTo(X,Y)_at_out
mustPointTo (c, d)
mustPointTo (c, d)
c a
c d
24
Propagating facts
define fact mustPointTo(XVar,YVar)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
mustPointTo (a, b)
mustPointTo (a, b)
if mustPointTo(X,Y)_at_in Æ currStmt Z W
Æ X ? Z then mustPointTo(X,Y)_at_out
mustPointTo (c, d)
c a
c a
mustPointTo (a, b)
mustPointTo (c, b)
mustPointTo (c, b)
if mustPointTo(X,Y)_at_in Æ currStmt Z
X then mustPointTo(Z,Y)_at_out
c d
25
Propagating facts
define fact mustPointTo(XVar,YVar)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
if mustPointTo(X,Y)_at_in Æ currStmt Z W
Æ X ? Z then mustPointTo(X,Y)_at_out
c a
if mustPointTo(X,Y)_at_in Æ currStmt Z
X then mustPointTo(Z,Y)_at_out
c d
26
Transformations
define fact mustPointTo(XVar,YVar)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
if mustPointTo(X,Y)_at_in Æ currStmt Z W
Æ X ? Z then mustPointTo(X,Y)_at_out
c a
c d
27
Transformations
define fact mustPointTo(XVar,YVar)
a b
if mustPointTo(X,Y)_at_in Æ currStmt X
Z then transform to Y Z
c a
mustPointTo (a, b)
mustPointTo (c, b)
mustPointTo (c, b)
c d
c d
b d
28
Semantics of a Rhodium opt

• Run all the propagations rules using optimistic
  iterative analysis starting with complete set of
  facts until the best fixed point is reached
• Then run all transformation rules
• For better precision, combine analyses and
  transformations using our previous composition
  framework POPL 02

29
More in Rhodium (see paper for details)

• Mixing facts
• Heap summaries
• MayPointTo analysis via MustNotPointTo
• Infinite domains
• Flow-sensitive and -insensitive
• Intraprocedural and interprocedural

30
Outline

• Overview
• Rhodium by example
• Checking correctness automatically
• Future work, related work and conclusion

31
Rhodium correctness checker
Rhodium optimization
Checker
Lemma VC ) correctness
VCGen
VC
opt- independent
Automatic theorem prover
32
Rhodium correctness checker
Rhodium optimization
define fact
if then transform
if then
Checker
Lemma VC ) correctness
VCGen
VC
opt- independent
Automatic theorem prover
33
Rhodium correctness checker
Rhodium optimization
define fact
if then transform
if then
Checker
Lemma VC ) correctness
Lemma Local VCs ) correctness
VCGen
Local VC
Local VC
opt- independent
Automatic theorem prover
34
Local correctness of prop. rules
define fact mustPointTo(XVar,YVar)
if mustPointTo(X,Y)_at_in Æ
currStmt Z X
then mustPointTo(Z,Y)_at_out
Z X
35
Local correctness of prop. rules
define fact mustPointTo(XVar,YVar)
Local VC sent to ATP
if mustPointTo(X,Y)_at_in Æ
currStmt Z X
then mustPointTo(Z,Y)_at_out
?in
Z X
Z X
?out
36
Local correctness of trans. rules
define fact mustPointTo(XVar,YVar)
with meaning X Y
Local VC sent to ATP
if mustPointTo(X,Y)_at_in Æ
if X Y (?in) Æ
X Z
?in
currStmt X Z
?out
Y Z
?in
?out
then transform to Y Z
then
X Z
X Z
Y Z
Y Z
?out
?out
?
37
More on correctness (see paper for details)

• Heap summaries
• Separating profitability from correctness
• Theorem stating soundness of the framework for
  creating interprocedural and flow-insensitive
  analyses

38
Outline

• Overview
• Rhodium by example
• Checking correctness automatically
• Future work, related work and conclusion

39
Current and future work

• Backward optimizations
• Infer rules from just the dataflow fact
  declarations and their meanings
• Debugging
• Efficient execution engine

40
Some related work

• Proving correctness by hand
• Abstract interpretation Cousot and Cousot 77,
  79
• Partial equivalence relations Benton 04
• Temporal logic Lacey et al. 02
• Proving correctness with interactive theorem
  prover
• Using Coq proof assistant Cachera et al. 04
• Testing correctness one compilation at a time
• Translation validation Pnueli et al. 98, Necula
  00
• Credible compilation Rinard 99
• Execution engines
• Incremental execution of transformations
  Sittampalam et al. 04
• Running opts specified with temporal logic
  Steffen 91

41
Conclusion

• Local rules in Rhodium are more expressive than
  Cobalts global condition
• The correctness checker found subtle bugs in our
  Rhodium opts
• Good step towards pushing more of the burden of
  writing compilers on to the computer