Provably Correct Compilers (Part 2)

1
Provably Correct Compilers (Part 2)

• Nazrul Alam and Krishnaprasad Vikram
• April 21, 2005

2
Todays Focus
Automated Soundness Proofs for Dataflow Analyses
and Transformations via Local Rules (Rhodium
Paper)
Sorin Lerner, Todd Millstein, Erika Rice, Craig
Chambers
3
Rhodium Successor of Cobalt

• 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

4
Recap from Last Class

• Optimization needs analysis.
• Each analysis is formulated as a global path
  condition in Cobalt.
• In Rhodium it is done with local rules.

5

• Similarities with Cobalt
• (Also helpful for refreshing your memory..)

6
Given
Rhodium Execution engine
Checker
Written by programmer
7
Given
Rhodium Execution engine
Checker
Written by programmer
8
Rdm Opt
Rdm Opt
Rdm Opt
9
Compiler
Rhodium Execution engine
Exec
Rdm Opt
Rdm Opt
Rdm Opt
10
Verification Task
Rdm Opt
Verification Task
Checker
Show that for any original program behavior
of original program behavior
of optimized program
Verification Task
11
Verification Task
Rdm Opt
Verification Task
Verification Task
12
Verification Task
Rdm Opt
Verification Task
Verification Task
13
Three techniques to simplify Verification Task
Rdm Opt

• Rhodium is declarative
• no loops, no branches, no program counter
• declare intent using rules
• execution engine takes care of the rest

14
Three techniques to simplify Verification Task
Rdm Opt

• Rhodium is declarative
• no loops, no branches, no program counter
• declare intent using rules
• execution engine takes care of the rest

15
Three techniques to simplify Verification Task
Heuristics not affecting correctness
Part that must be reasoned about
Rdm Opt

• Rhodium is declarative
• Factor out heuristics
• legal transformations
• vs. profitable transformations

16
Three techniques to simplify Verification Task
Heuristics not affecting correctness
Part that must be reasoned about

• Rhodium is declarative
• Factor out heuristics
• legal transformations
• vs. profitable transformations

17
Three techniques to simplify Verification Task
opt-dependent

• Rhodium is declarative
• Factor out heuristics
• Split verification task
• opt-dependent
• vs. opt-independent

opt-independent
18
Three techniques to simplify Verification Task

• Rhodium is declarative
• Factor out heuristics
• Split verification task
• opt-dependent
• vs. opt-independent

19
Three techniques to simplify Verification Task

• Rhodium is declarative
• Factor out heuristics
• Split verification task
• opt-dependent
• vs. opt-independent

20
Three techniques to simplify Verification Task

1. Rhodium is declarative
2. Factor out heuristics
3. Split verification task

• Result
• Expressive language
• Automated correctness checking

21

• Where is the difference?

Rohodiums local rules are different from
Cobalts global condition
Then how exactly Rhodium works?
22
MustPointTo analysis
a b
c a
d c
d b
23
MustPointTo info in Rhodium
a b
c a
d c
24
MustPointTo info in Rhodium
a b
a b
c a
c a
d c
d c
25
MustPointTo info in Rhodium
define fact mustPointTo(XVar,YVar) with
meaning s( X) s(Y)
a b
Fact correct on edge if
whenever program execution reaches edge, meaning
of fact evaluates to true in the program state
c a
d c
26
Propagating facts
define fact mustPointTo(XVar,YVar) with
meaning s(X) s(Y)
a b
c a
d c
27
Propagating facts
define fact mustPointTo(XVar,YVar) with
meaning s(X) s(Y)
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
c a
d c
28
Propagating facts
define fact mustPointTo(XVar,YVar) with
meaning s(X) s(Y)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
c a
d c
29
Propagating facts
define fact mustPointTo(XVar,YVar) with
meaning s(X) s(Y)
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
X then mustPointTo(Z,Y)_at_out
c a
c a
mustPointTo (a, b)
mustPointTo (c, b)
mustPointTo (c, b)
d c
30
Propagating facts
define fact mustPointTo(XVar,YVar) with
meaning s(X ) s(Y)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
if mustPointTo(X,Y)_at_in ?? currStmt Z
X then mustPointTo(Z,Y)_at_out
c a
d c
31
Transformations
define fact mustPointTo(XVar,YVar) with
meaning s(X ) s(Y)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
if mustPointTo(X,Y)_at_in ? currStmt Z
X then mustPointTo(Z,Y)_at_out
c a
mustPointTo (a, b)
if mustPointTo(X,Y)_at_in ? currStmt Z
X then transform to Z Y
mustPointTo (c, b)
mustPointTo (c, b)
d c
d c
d b
32
Transformations
define fact mustPointTo(XVar,YVar) with
meaning s(X ) s(Y)
a b
if currStmt X Y then
mustPointTo(X,Y)_at_out
if mustPointTo(X,Y)_at_in ? currStmt Z
X then mustPointTo(Z,Y)_at_out
c a
mustPointTo (a, b)
if mustPointTo(X,Y)_at_in ? currStmt Z
X then transform to Z Y
mustPointTo (c, b)
d c
d b
33
Semantics of a Rhodium opt

• Run propagation rules in a loop until there are
  no more changes (optimistic iterative analysis)
• Then run transformation rules
• Then run profitability heuristics
• For better precision, combine propagation rules
  and transformations rules.

34

• Rhodium is more expressive

35
Cobalt Simple Pointer Analysis
36
Rhodium version..
37
And Rhodium can do more
..Can not be expressed in Cobalt
38
Arithmetic Simplification Optimization
39
Arithmetic Simplification Optimization (Cont.)
40
Loop induction-variable strength reduction
41
Loop induction-variable strength reduction (cont.)
42

• Checking Rhodium optimizations

43
Rhodium correctness checker
Rdm Opt
44
Rhodium correctness checker
Rdm Opt
45
Rhodium correctness checker
Rdm Opt
Checker
Automatic theorem prover
46
Rhodium correctness checker
Rhodium optimization
define fact
if then transform
if then
Profitability heuristics
Checker
Automatic theorem prover
47
Rhodium correctness checker
Rhodium optimization
define fact
if then transform
if then
Checker
Automatic theorem prover
48
Rhodium correctness checker
Rhodium optimization
Opt-independent
define fact
if then
if then transform
Checker
VCGen
VCGen
LocalVC
LocalVC
Opt-dependent
Automatic theorem prover
49
Local correctness of prop. rules
Fact correct on edge iff
define fact mustPointTo(X,Y) with meaning s(X)
s(Y)
whenever program execution reaches edge, meaning
of fact evaluates to true in the program state
if mustPointTo(X,Y)_at_in ?
currStmt Z X
then mustPointTo(Z,Y)_at_out
50
Local correctness of prop. rules
Local VC (generated and proven automatically)
define fact mustPointTo(X,Y) with meaning
s(X)s(Y)
Assume
All incoming facts are correct
if mustPointTo(X,Y)_at_in ?
currStmt Z X
Propagated factis correct
Show
then mustPointTo(Z,Y)_at_out
51
Local correctness of prop. rules
Local VC (generated and proven automatically)
define fact mustPointTo(X,Y) with meaning X Y
52

• Evaluation

53
Dimensions of evaluation

• Correctness guarantees
• Usefulness of the checker
• Expressiveness

54
Correctness guarantees

• Ease of use
• Guarantees
• Usefulness
• Expressiveness

• Once checked, optimizations are guaranteed to be
  correct
• Caveat trusted computing base
• execution engine
• checker implementation
• proofs done by hand once by Lerner.
• Adding a new optimization does not increase the
  size of the trusted computing base

55
Usefulness of the checker

• Ease of use
• Guarantees
• Usefulness
• Expressiveness

• Found subtle bugs in Lerners initial
  implementation of various optimizations

define fact equals(XVar, EExpr) with
meaning s(X) s(E)
if currStmt X E then equals(X,E)_at_out
56
Usefulness of the checker

• Ease of use
• Guarantees
• Usefulness
• Expressiveness

• Found subtle bugs in Lerners initial
  implementation of various optimizations

define fact equals(XVar, EExpr) with
meaning s(X) s(E)
if currStmt X E then equals(X,E)_at_out
if currStmt X E ? X does not appear in
E then equals(X,E)_at_out
57
Usefulness of the checker

• Ease of use
• Guarantees
• Usefulness
• Expressiveness

• Found subtle bugs in Lerners initial
  implementation of various optimizations

define fact equals(XVar, EExpr) with
meaning s(X) s(E)
x x 1
x x 1
x y 1
if currStmt X E Æ X does not appear in
E then equals(X,E)_at_out
if currStmt X E ? E does not use
X then equals(X,E)_at_out
equals (x , x 1)
equals (x , y 1)
58
Rhodium expressiveness

• Ease of use
• Guarantees
• Usefulness
• Expressiveness

• Traditional optimizations
• const prop and folding, branch folding, dead
  assignment elim, common sub-expression elim,
  partial redundancy elim, partial dead assignment
  elim, arithmetic invariant detection, and integer
  range analysis.
• Pointer analyses
• must-point-to analysis, Andersen's may-point-to
  analysis with heap summaries
• Loop opts
• loop-induction-variable strength reduction, code
  hoisting, code sinking
• Array opts
• constant propagation through array elements,
  redundant array load elimination

59
Expressiveness limitations

• Ease of use
• Guarantees
• Usefulness
• Expressiveness

• May not be able to express your optimization in
  Rhodium
• opts that build complicated data structures
• opts that perform complicated many-to-many
  transformations (e.g. loop fusion, loop
  unrolling)
• A correct Rhodium optimization may be rejected by
  the correctness checker
• limitations of the theorem prover
• limitations of first-order logic

60
Summary

• Rhodium system
• makes it easier to write optimizations
• provides correctness guarantees
• is expressive enough for realistic optimizations
• Rhodium system provides a foundation for safe
  extensible program manipulators

61
Future works

• Overcome the limitation of Rhodium
• opts that build complicated data structures
• opts that perform complicated many-to-many
  transformations (e.g. loop fusion, loop
  unrolling)
• Overcoming the limitation of theorem prover
• Simplify is conservative
• Using higher order logic?

62
Future works..

• Automatically infer the whole compiler from a
  high level specification
• Infer analyses
• Infer transformations
• Program optimizations by demonstration
• Automatically pick good data representations
• Automatically explore the tradeoffs between
  scalability and precision

63
References

• Correctness
• By hand Cousot and Cousot 77, 79, Benton 04,
  Lacey et al. 02
• With interactive theorem prover Cachera et al.
  04
• One compilation at a time Pnueli et al. 98,
  Necula 00, Rinard 99
• Declarative languages for writing transformations
• Attribute grammars Reps and Teitelbaum 88
• Temporal logic Steffen 91, Lacey et al. 02
• Execution engines
• Incremental execution of transformations
  Sittampalam et al. 04
• Running opts specified with temporal logic
  Steffen 91

64
More facts
define fact mustNotPointTo(XVar,YVar) with
meaning s (X) ? s (Y)
define fact doesNotPointIntoHeap(XVar) with
meaning YVar and s (X) s (Y)
define fact hasConstantValue(XVar,CConst) with
meaning s(X) C
65
More rules
if currStmt X A ? mustNotPointToHeap(A)
_at_in ? ? BVar . mayPointTo(A,B)_at_in ??
mustNotPointTo(B,Y) then mustNotPointTo(X,Y)_at_out