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

▶
formally proving a compiler transformation safe
SMART_READER_LITE
LIVE PREVIEW

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

Mar 26, 2023 344 likes •785 views

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

slide-1
SLIDE 1

1

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

PROGRAMMING PARADIGMS GROUP

Formally Proving a Compiler Transformation Safe

Joachim Breitner Haskell Symposium 2015 3 August 2015, Vancouver

KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association

www.kit.edu

slide-2
SLIDE 2

Short summary

2

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

I formally proved that

Call Arity is safe.

slide-3
SLIDE 3

Short summary

2

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

I formally proved that

Call Arity is safe. W H A B

slide-4
SLIDE 4

Short summary

2

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

I formally proved that

Call Arity is safe. “What exactly have you shown?” H A B

slide-5
SLIDE 5

Short summary

2

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

I formally proved that

Call Arity is safe. “What exactly have you shown?” “H ow did you prove that?” A B

slide-6
SLIDE 6

Short summary

2

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

I formally proved that

Call Arity is safe. “What exactly have you shown?” “H ow did you prove that?” “A re you sure about this?” B

slide-7
SLIDE 7

Short summary

2

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

I formally proved that

Call Arity is safe. “What exactly have you shown?” “H ow did you prove that?” “A re you sure about this?” “B ut, . . . !”

slide-8
SLIDE 8

What exactly is. . . Call Arity?

3

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Call Arity is an arity analysis: let fac 10 = id fac x = ńy. fac (x+1) (y∗x) in fac 0 1 = ⇒ let fac 10 y = y fac x y = fac (x+1) (y∗x) in fac 0 1

slide-9
SLIDE 9

What exactly is. . . Call Arity?

3

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Call Arity is an arity analysis: let fac 10 = id fac x = ńy. fac (x+1) (y∗x) in fac 0 1 = ⇒ let fac 10 y = y fac x y = fac (x+1) (y∗x) in fac 0 1 So far: Naive forward arity analysis, see Gill’s PhD thesis from 96

slide-10
SLIDE 10

What exactly is. . . the problem?

4

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Eta-expanding a thunk is tricky: let thunk = f x in . . . = ⇒ let thunk y = f x y in . . .

slide-11
SLIDE 11

What exactly is. . . the problem?

4

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Eta-expanding a thunk is tricky: let thunk = f x in . . . = ⇒ let thunk y = f x y in . . .

Sharing can be lost!

slide-12
SLIDE 12

What exactly is. . . the problem?

4

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Eta-expanding a thunk is tricky: let thunk = f x in . . . = ⇒ let thunk y = f x y in . . .

Sharing can be lost!

(unless “thunk” is used at most once in “. . . ”)

slide-13
SLIDE 13

What exactly is. . . co-call cardinality analysis?

5

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

G0(if p then x else y) = p x y G0(f x y) = f x y

slide-14
SLIDE 14

What exactly is. . . Call Arity?

6

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Call Arity = Arity analysis with co-call cardinality analysis

slide-15
SLIDE 15

What exactly is. . . Call Arity?

6

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Call Arity = Arity analysis with co-call cardinality analysis

Now foldl can be a good consumer in list-fusion!

slide-16
SLIDE 16

What exactly is. . . “safe”?

7

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Safety: It is safe for the compiler to apply the

transformation, i.e. the performance will not degrade.

slide-17
SLIDE 17

What exactly is. . . “safe”?

7

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Safety: It is safe for the compiler to apply the

transformation, i.e. the performance will not degrade. Yes, it is synonymous to “improvement”.

slide-18
SLIDE 18

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓

slide-19
SLIDE 19

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓ Too much eta-expansion ⇓

slide-20
SLIDE 20

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓

slide-21
SLIDE 21

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated ⇓

slide-22
SLIDE 22

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated ⇓ Allocation is increasing

slide-23
SLIDE 23

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated ⇓ Allocation is increasing Theorem: Call Arity does not increase the number

  • f allocations
slide-24
SLIDE 24

What exactly is. . . could possibly go wrong?

8

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

A bug in Call Arity ⇓ Too much eta-expansion ⇓ Loss of sharing ⇓ Work is duplicated ⇓ Allocation is increasing No (such) bug ⇑ Theorem: Call Arity does not increase the number

  • f allocations
slide-25
SLIDE 25

How did you prove that?

9

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

1st ingredient Sufficiently detailed semantics: Launchbury’s natural semantics for lazy evaluation. Γ heap before : e current expression ⇓ ∆ heap afterwards : v final value

slide-26
SLIDE 26

How did you prove that?

9

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

1st ingredient Sufficiently detailed semantics: Sestoft’s mark-1 virtual machine (Γ current heap , e current expression , S current stack ) ⇒ (Γ′ next heap , e′ next expression , S′ next stack )

slide-27
SLIDE 27

How did you prove that?

10

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

2nd ingredient Abstract view on what calls what: Trace trees!

slide-28
SLIDE 28

How did you prove that?

10

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

2nd ingredient Abstract view on what calls what: Trace trees! T0(if p then x else y) = y x p T0(f x y) = y x y y x x f

slide-29
SLIDE 29

How did you prove that?

10

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

2nd ingredient Abstract view on what calls what: Trace trees! T0(if p then x else y) = y x p T0(f x y) = y x y y x x f Co-call graphs approximates trace trees It even is a Galois immersion.

slide-30
SLIDE 30

How did you prove that?

11

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

3nd ingredient A way to handle a large proof: Refinement proofs

slide-31
SLIDE 31

How did you prove that?

11

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

3nd ingredient A way to handle a large proof: Refinement proofs Arity analysis + any cardinality analysis

impl.

← − − Arity analysis + a trace tree analysis

approx.

← − − − − Arity analysis + a co-call graph analysis

impl.

← − − Call Arity

slide-32
SLIDE 32

Are you sure?

12

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Syntax (using Nominal logic) Semantics (Launchbury, Sestoft, denotational) Data types (Co-call graphs, trace trees) ... and of course the proofs

λ → ∀

=

Isabelle

β α

H O L

slide-33
SLIDE 33
  • But. . .

13

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

The formalization gap!

slide-34
SLIDE 34
  • But. . .

13

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

The formalization gap!

slide-35
SLIDE 35
  • But. . .

13

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

The formalization gap!

slide-36
SLIDE 36
  • But. . .

13

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

The formalization gap!

slide-37
SLIDE 37

Bug #10176

14

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

let foo x = error ". . . " in . . . case foo a b of . . . ⇓ Strictness analyzer let foo x = error ". . . "

  • - Strictness: <L,U>b

in . . . case foo a b of . . . ⇓ Call Arity let foo x y = error ". . . " y

  • - Strictness: <L,U>b

in . . . case foo a b of . . . ⇓ Simplifier let foo x y = error ". . . " y

  • - Strictness: <L,U>b

in . . . case foo a of {}

slide-38
SLIDE 38

Conclusion

15

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Yes, we can. . .

formally prove a compiler transformation to be safe.

slide-39
SLIDE 39

Conclusion

15

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Yes, we can. . .

formally prove a compiler transformation to be safe. Increased the quality Uncovered a bug missed by tests. Refactorable when the code changes Provides high assurance

slide-40
SLIDE 40

Conclusion

15

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Yes, we can. . .

formally prove a compiler transformation to be safe. Increased the quality Uncovered a bug missed by tests. Refactorable when the code changes Provides high assurance Very tedious Still only worth it in certain domains? Formalization gap Is GHC the wrong target?

slide-41
SLIDE 41

16

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Thank you for your attention.

Minecraft image c CC-BY-NC-SA iScr34m http://fav.me/d3lhdq2 Island image c CC0 CSITDMS https://pixabay.com/de/insel-strand-sandstrand-philippinen-218578/ Bridge image c CC-BY-SA Sulfur https://commons.wikimedia.org/wiki/File:Hoan_Bridge.jpg Car drawing c CC-BY-NC Randall Munroe https://what-if.xkcd.com/61/

slide-42
SLIDE 42

Backup slide: How tedious, really?

17

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

AEnv AList-Utils AList-Utils-HOLCF AList-Utils-Nominal Abstract-Denotational-Props AbstractDenotational AbstractTransform AnalBinds Arity Arity-Nominal ArityAnalysisAbinds ArityAnalysisCorrDenotational ArityAnalysisFix ArityAnalysisFixProps ArityAnalysisSig ArityAnalysisSpec ArityAnalysisStack ArityConsistent ArityEtaExpansion ArityEtaExpansionSafe ArityStack ArityTransform ArityTransformSafe CallArityEnd2End CallArityEnd2EndSafe CardArityTransformSafe Cardinality-Domain Cardinality-Domain-Lists CardinalityAnalysisSig CardinalityAnalysisSpec CoCallAnalysisBinds CoCallAnalysisImpl CoCallAnalysisSig CoCallAnalysisSpec CoCallAritySig CoCallFix CoCallGraph CoCallGraph-Nominal CoCallGraph-TTree CoCallImplSafe CoCallImplTTree CoCallImplTTreeSafe ConstOn Denotational Env Env-HOLCF Env-Nominal Env-Set-Cpo EtaExpansion EtaExpansionSafe EvalHeap HOLCF-Join HOLCF-Join-Classes HOLCF-Utils HasESem HeapSemantics Iterative List-Interleavings NoCardinalityAnalysis Nominal-HOLCF Nominal-Utils Pointwise Sestoft SestoftConf SestoftGC Set-Cpo Substitution TTree TTree-HOLCF TTreeAnalysisSig TTreeAnalysisSpec TTreeImplCardinality TTreeImplCardinalitySafe Terms TransformTools TrivialArityAnal Value Value-Nominal Vars [HOLCF-Nominal2]

9 man-months 12,000 loc 1,200 lemmas 79 theories

slide-43
SLIDE 43

Backup slide: That bug that was found

18

2015-09-03 Joachim Breitner - Formally Proving a Compiler Transformation Safe PROGRAMMING PARADIGMS GROUP

Call Arity initially would eta-expand thunks in a recursive group, as long as the recursion is linear. foo a = let go | a == "m" = ń x. if x == 0 then 1 else x ∗ go (x-1) | a == "p" = ń x. if x == 0 then 0 else x + go (x-1) in go 100