Two Approaches of
Showing Program
Equivalence
Borys Bradel
1
Introduction


Two programs are equivalent if they produce the
same effect
Try for all possible inputs
 Too
many possibilities
 Security



Direct proof
Compute necessary conditions
Use a theorem prover
2
Motivation - Verification
Non-optimizing compilers
 Optimizing compilers

 Local
optimizations
 Global optimizations are not verifiable

Still want to verify
 Compare
to non-optimized
3
Outline

Background
 Hoare
 ACL2

Calculus
Methodology
 Program Representation
 Precondition Computation


Related Work
Conclusion
4
Hoare Calculus









{P} v:=u {Q} = P  Q[v/u]
{P} C1 ; C2 {Q} = {P} C1 {R}, {R} C2 {Q}
{P} if B then C1 else C2 {Q} =
{P and B} C1 {Q}, {P and not B} C2 {Q}
wlp(u:=v,Q) = Q[v/u]
wlp(C1 ; C2, Q) = wlp (C1, wlp(C2, Q))
wlp(if B then C1 else C2, Q) =
(B and wlp (C1, Q)) or (not B and wlp (C2, Q))
y:=2+3 ; x:=5+y {x=10}
y:=2+3 {10=5+y}
{10=5+(2+3)}
5
ACL2
Proofs on recursively defined functions
 Subset of Common Lisp
 Information is stored in books

(defun our-add (x y) (+ x y))
 (defthm our-add-is-commutative
(equal (our-add a b) (our-add b a)))

6
Program Representation
Return: r1
Instructions:
'((add r1 4 3)
(add r3 r1 5)
(ble r1 r3
((add r2 5 4)
(add r5 6 5))
((add r2 6 2)
(add r6 6 3)))
(add r4 r1 r2)))
R1:=4+3
R3:=R1+5
if R1 ≤ R3
F
T
R2:=5+4
R5:=6+5
R2:=6+2
R6:=6+3
R4:=R1+R2
return R1
7
Program Representation
R1:=4+3
R3:=R1+5
if R1 ≤ R3
F
T
R2:=5+4
R5:=6+5
R2:=6+2
R6:=6+3
R4:=R1+R2
return R1
The
program is executable:
(func1 0)  7
Equivalence is provable:
(defthm program-equivalence
(equal (func1 A) (func2 A)))
func1(A)
R1:=4+3
R3:=R1+5
(R2 R1):=func1-branch-2(R3,R1)
R4:=R1+R2
return R1
func1-branch-2(R3,R1)
if R1 ≤ R3 then
R2:=5+4
R5:=6+5
else
R2:=6+2
R6:=6+3
end if
return (R2 R1)
8
Precondition Computation
R1:=4+3
R3:=R1+5
if R1 ≤ R3
R11:=4+3
R13:=R11+5
if R11 ≤ R13
F
T
R2:=5+4
R5:=6+5
R2:=6+2
R6:=6+3
R4:=R1+R2
return R1
F
T
R12:=5+4
R15:=6+5
R12:=6+2
R16:=6+3
R14:=R11+R12
return R11
9
Precondition Computation
R1:=4+3
R3:=R1+5
if R1 ≤ R3
R11:=4+3
R13:=R11+5
if R11 ≤ R13
R1=R11
T,T
R2:=5+4
R5:=6+5
F,F
R12:=5+4
R15:=6+5
R2:=6+2
R6:=6+3
R1=R11
(R1=R11  R1≤R3  R11≤R13)

(R1=R11  R1>R3  R11>R13)
R12:=6+2
R16:=6+3
R1=R11
R4:=R1+R2
return R1
R14:=R11+R12
return R11
R1=R11
10
Precondition Computation

Precondition for branches:


Precondition for: R3:=R1+5, R13:=R11+5


(R1=R11  R1≤R3  R11≤R13)  (R1=R11  R1>R3 
R11>R13)
(R1=R11  R1≤(R1+5)  R11≤(R11+5))  (R1=R11  R1>(R1+5)
 R11>(R11+5))
Precondition for R1:=4+3, R11:=4+3


((3+4)=(3+4)  (3+4)≤((3+4)+5)  (3+4)≤((3+4)+5)) 
((3+4)=(3+4)  (3+4)>((3+4)+5)  (3+4)>((3+4)+5))
(TTT)(TFF) = T
11
Related Work
Robert van Engelen, David Whalley, and
Xin Yuan. "Automatic Validation of CodeImproving Transformations"
 George C. Necula, “Translation Validation
for an Optimizing Compiler”
 Many more, although less so.

12
Conclusion

A theorem prover is useful for validation
 No
need to code the entire logic engine
 Difficult to incorporate

Validation is slow
 Algorithms
must be selected carefully
13
Future Work

Add loop, method, and memory handling
 Cannot

Add simplification of constraints
 Right

analyze real programs
now constraints grow too quickly
Automate
 Must
identify why the proof did not complete
 May require new theorems, better use of
books
14