1 / 14

Two Approaches of Showing Program Equivalence

Two Approaches of Showing Program Equivalence. Borys Bradel. 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. Motivation - Verification.

alika-hays
Télécharger la présentation

Two Approaches of Showing Program Equivalence

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Two Approaches of Showing Program Equivalence Borys Bradel

  2. 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

  3. Motivation - Verification • Non-optimizing compilers • Optimizing compilers • Local optimizations • Global optimizations are not verifiable • Still want to verify • Compare to non-optimized

  4. Outline • Background • Hoare Calculus • ACL2 • Methodology • Program Representation • Precondition Computation • Related Work • Conclusion

  5. 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)}

  6. 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)))

  7. 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

  8. Program Representation R1:=4+3 R3:=R1+5 if R1 ≤ R3 func1(A) R1:=4+3 R3:=R1+5 (R2 R1):=func1-branch-2(R3,R1) R4:=R1+R2 return R1 F T R2:=5+4 R5:=6+5 R2:=6+2 R6:=6+3 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) R4:=R1+R2 return R1 • The program is executable: • (func1 0)  7 • Equivalence is provable: • (defthm program-equivalence • (equal (func1 A) (func2 A)))

  9. R1:=4+3 R3:=R1+5 if R1 ≤ R3 R11:=4+3 R13:=R11+5 if R11 ≤ R13 F F T T R2:=5+4 R5:=6+5 R2:=6+2 R6:=6+3 R12:=5+4 R15:=6+5 R12:=6+2 R16:=6+3 R4:=R1+R2 return R1 R14:=R11+R12 return R11 Precondition Computation

  10. Precondition Computation R1:=4+3 R3:=R1+5 if R1 ≤ R3 R11:=4+3 R13:=R11+5 if R11 ≤ R13 (R1=R11  R1≤R3  R11≤R13)  (R1=R11  R1>R3  R11>R13) R1=R11 T,T F,F R2:=5+4 R5:=6+5 R12:=5+4 R15:=6+5 R2:=6+2 R6:=6+3 R12:=6+2 R16:=6+3 R1=R11 R1=R11 R4:=R1+R2 return R1 R14:=R11+R12 return R11 R1=R11

  11. Precondition Computation • Precondition for branches: • (R1=R11  R1≤R3  R11≤R13)  (R1=R11  R1>R3  R11>R13) • Precondition for: R3:=R1+5, R13:=R11+5 • (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

  12. Related Work • Robert van Engelen, David Whalley, and Xin Yuan. "Automatic Validation of Code-Improving Transformations" • George C. Necula, “Translation Validation for an Optimizing Compiler” • Many more, although less so.

  13. 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

  14. Future Work • Add loop, method, and memory handling • Cannot analyze real programs • Add simplification of constraints • Right now constraints grow too quickly • Automate • Must identify why the proof did not complete • May require new theorems, better use of books

More Related