formally proving a compiler transformation safe
play

Formally Proving a Compiler Transformation Safe Joachim Breitner - PowerPoint PPT Presentation

Formally Proving a Compiler Transformation Safe Joachim Breitner Haskell Symposium 2015 3 August 2015, Vancouver PROGRAMMING PARADIGMS GROUP 1 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING


  1. Formally Proving a Compiler Transformation Safe Joachim Breitner Haskell Symposium 2015 3 August 2015, Vancouver PROGRAMMING PARADIGMS GROUP 1 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP KIT – University of the State of Baden-Wuerttemberg and www.kit.edu National Research Center of the Helmholtz Association

  2. Short summary I formally proved that Call Arity is safe. 2 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  3. Short summary I formally proved that Call Arity is safe. W H A B 2 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  4. Short summary I formally proved that Call Arity is safe. “W hat exactly have you shown?” H A B 2 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  5. Short summary I formally proved that Call Arity is safe. “W hat exactly have you shown?” “H ow did you prove that?” A B 2 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  6. Short summary I formally proved that Call Arity is safe. “W hat exactly have you shown?” “H ow did you prove that?” “A re you sure about this?” B 2 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  7. Short summary I formally proved that Call Arity is safe. “W hat exactly have you shown?” “H ow did you prove that?” “A re you sure about this?” “B ut, . . . !” 2 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  8. What exactly is. . . Call Arity? Call Arity is an arity analysis: let fac 10 = id let fac 10 y = y = fac x = ń y. fac (x+1) (y ∗ x) ⇒ fac x y = fac (x+1) (y ∗ x) in fac 0 1 in fac 0 1 3 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  9. What exactly is. . . Call Arity? Call Arity is an arity analysis: let fac 10 = id let fac 10 y = y = fac x = ń y. fac (x+1) (y ∗ x) ⇒ fac x y = fac (x+1) (y ∗ x) in fac 0 1 in fac 0 1 So far: Naive forward arity analysis, see Gill’s PhD thesis from 96 3 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  10. What exactly is. . . the problem? Eta-expanding a thunk is tricky: let thunk = f x let thunk y = f x y = ⇒ in . . . in . . . 4 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  11. What exactly is. . . the problem? Eta-expanding a thunk is tricky: let thunk = f x let thunk y = f x y = ⇒ in . . . in . . . Sharing can be lost! 4 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  12. What exactly is. . . the problem? Eta-expanding a thunk is tricky: let thunk = f x let thunk y = f x y = ⇒ in . . . in . . . Sharing can be lost! (unless “thunk” is used at most once in “. . . ”) 4 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  13. What exactly is. . . co-call cardinality analysis? x G 0 ( if p then x else y ) = p y x G 0 ( f x y ) = f y 5 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  14. What exactly is. . . Call Arity? Call Arity = Arity analysis with co-call cardinality analysis 6 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  15. What exactly is. . . Call Arity? Call Arity = Arity analysis with co-call cardinality analysis Now foldl can be a good consumer in list-fusion! 6 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  16. What exactly is. . . “safe”? Safety: It is safe for the compiler to apply the transformation, i.e. the performance will not degrade. 7 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  17. What exactly is. . . “safe”? Safety: It is safe for the compiler to apply the transformation, i.e. the performance will not degrade. Yes, it is synonymous to “improvement”. 7 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  18. What exactly is. . . could possibly go wrong? A bug in Call Arity ⇓ 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  19. What exactly is. . . could possibly go wrong? A bug in Call Arity ⇓ Too much eta-expansion ⇓ 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  20. What exactly is. . . could possibly go wrong? A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  21. What exactly is. . . could possibly go wrong? A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated ⇓ 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  22. What exactly is. . . could possibly go wrong? A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated ⇓ Allocation is increasing 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  23. What exactly is. . . could possibly go wrong? A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated Theorem: Call Arity does not ⇓ increase the number Allocation is increasing of allocations 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  24. What exactly is. . . could possibly go wrong? A bug in Call Arity No (such) bug ⇓ Too much eta-expansion ⇓ ⇑ Loss of sharing ⇓ Work is duplicated Theorem: Call Arity does not ⇓ increase the number Allocation is increasing of allocations 8 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  25. How did you prove that? 1st ingredient Sufficiently detailed semantics: Launchbury’s natural semantics for lazy evaluation. : e ⇓ ∆ : v Γ heap before final value current expression heap afterwards 9 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  26. How did you prove that? 1st ingredient Sufficiently detailed semantics: Sestoft’s mark-1 virtual machine ) ⇒ ( Γ ′ , e ′ , S ′ ( Γ , e , S ) current heap next stack current expression next expression next heap current stack 9 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  27. How did you prove that? 2nd ingredient Abstract view on what calls what: Trace trees! 10 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  28. How did you prove that? 2nd ingredient Abstract view on what calls what: Trace trees! x p T 0 ( if p then x else y ) = y x x y f T 0 ( f x y ) = x y y 10 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  29. How did you prove that? 2nd ingredient Abstract view on what calls what: Trace trees! x p T 0 ( if p then x else y ) = y x x y f T 0 ( f x y ) = x y y Co-call graphs approximates trace trees It even is a Galois immersion. 10 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  30. How did you prove that? 3nd ingredient A way to handle a large proof: Refinement proofs 11 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  31. How did you prove that? 3nd ingredient A way to handle a large proof: Refinement proofs Arity Arity Arity analysis analysis analysis + + + impl. approx. impl. ← − − ← − − − − ← − − Call Arity any a a co-call cardinality trace tree graph analysis analysis analysis 11 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  32. Are you sure? Isabelle H O L Syntax (using Nominal logic) ∀ Semantics (Launchbury, Sestoft, denotational) = Data types (Co-call graphs, trace trees) α λ β → ... and of course the proofs 12 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  33. But. . . The formalization gap! 13 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  34. But. . . The formalization gap! 13 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  35. But. . . The formalization gap! 13 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

  36. But. . . The formalization gap! 13 2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend