Building “Correct” Compilers

Building “Correct” Compilers
K. Vikram and S. M. Nazrul A.

Outline Introduction: Setting the high level context Motivation
Detours Automated Theorem Proving Compiler Optimizations thru Dataflow Analysis Overview of the Cobalt System Forward optimizations in cobalt Proving Cobalt Optimizations Correct Profitability Heuristics Pure Analyses Concluding Remarks

The Seven Grand Challenges
Introduction The Seven Grand Challenges In Vivo  In Silico Science for Global Ubiquitous Computing Memories for Life Scalable Ubiquitous Computing Systems The Architecture of the Brain and Mind Dependable Systems Evolution Journeys in Non-classical computations

The Seven Grand Challenges
Introduction The Seven Grand Challenges In Vivo  In Silico Science for Global Ubiquitous Computing Memories for Life Scalable Ubiquitous Computing Systems The Architecture of the Brain and Mind Dependable Systems Evolution Journeys in Non-classical computations The dependable systems evolution challenge seems to be the most immediately required challenge to be met. The others are almost a luxury, but this one is a fair necessity.

Dependable Systems Evolution
Introduction Dependable Systems Evolution A long standing problem Loss of financial resources, human lives Compare with other engineering fields! Non-functional requirements Safety, Reliability, Availability, Security, etc.

Why the sudden interest?
Introduction Why the sudden interest? Was difficult so far, but now … Greater Technology Push Model checkers, theorem provers, programming theories and other formal methods Greater Market Pull Increased dependence on computing

A small but significant step
Introduction A small but significant step Building Correct Compilers

Why are correct compilers hard to build?
Motivation Why are correct compilers hard to build? Bugs don’t manifest themselves easily Where is the bug – program or compiler? Possible solutions Check semantic equivalence of the two programs (translation validation, etc.) Prove compilers sound (manually) Drawbacks? Conservative, Difficult, Actual code not verified

Testing Compiled Source Prog compiler To get benefits, must:
Motivation Testing Source Compiled Prog compiler exp- ected output output input DIFF run! To get benefits, must: run over many inputs compile many test cases No correctness guarantees: neither for the compiled prog nor for the compiler

Verify each compilation
Motivation Verify each compilation Source Compiled Prog compiler Semantic DIFF Translation validation [Pnueli et al 98, Necula 00] Credible compilation [Rinard 99] Compiler can still have bugs. Compile time increases. “Semantic Diff” is hard.

Proving the whole compiler correct
Motivation Proving the whole compiler correct Source Compiled Prog compiler Correctness checker

Proving the whole compiler correct
Motivation Proving the whole compiler correct compiler Correctness checker Option 1: Prove compiler correct by hand. Proofs are long… And hard. Compilers are proven correct as written on paper. What about the implementation? Correctness checker Link? Proof Proof Proof «¬  $  \ r t  l / .

gcc-bugs mailing list And this is only for February 2003!
Motivation gcc-bugs mailing list Searched for “incorrect” and “wrong” in the gcc-bugs mailing list. Some of the results: c/9525: incorrect code generation on SSE2 intrinsics target/7336: [ARM] With -Os option, gcc incorrectly computes the elimination offset optimization/9325: wrong conversion of constants: (int)(float)(int) (INT_MAX) optimization/6537: For -O (but not -O2 or -O0) incorrect assembly is generated optimization/6891: G++ generates incorrect code when -Os is used optimization/8613: [3.2/3.3/3.4 regression] -O2 optimization generates wrong code target/9732: PPC32: Wrong code with -O2 –fPIC c/8224: Incorrect joining of signed and unsigned division … And this is only for February 2003! On a mature compiler!

Need for Automation compiler
Motivation Need for Automation compiler This approach: proves compiler correct automatically. Correctness checker Automatic Theorem Prover

This seems really hard! Task of proving compiler correct
The Challenge This seems really hard! Task of proving compiler correct Complexity of proving a compiler correct. Complexity that an automatic theorem prover can handle. Automatic Theorem Prover

Automated Theorem Proving
Brief detour thru ATP Started with AI applications Reasoning about FOL sound and complete 1965: Unification and Resolution Combinatorial Explosion. SAT (NP-Complete) and FOL (decidable) Refinements of Resolution, Term Rewriting, Higher order Logics Interactive Theorem Proving Efficient Implementation Techniques Coq, Nuprl, Isabelle, Twelf, PVS, Simplify, etc.

Focus on Optimizations
Optimizations are the most error prone Only phase that performs transformations that can potentially change semantics Front-end and back-end are relatively static

Optimizations Common Optimizations Constant Propagation: replace constant valued variables with constants Common sub-expression elimination: avoid recomputing value if value has been computed earlier in the program Loop invariant removal: move computations into less frequently executed portions of the program Strength Reduction: replace expensive operations (multiplication) with simpler ones (addition) Dead code removal: eliminate unreachable code and code that is irrelevant to the output of the program

Constant Propagation Examples
Optimizations Constant Propagation Examples

Constant Propagation Condition
Optimizations Constant Propagation Condition Suppose x is used at program point p If on all possible execution paths from START of procedure to p x has constant value c at p then replace x by c

The Analysis Algorithm
Optimizations The Analysis Algorithm Build the control flow graph (CFG) of the program Make flow of control explicit Perform symbolic evaluation to determine constants Replace constant-valued variable uses by their values and simplify expressions and control flow

Optimizations Building the CFG

Building the CFG Composed of Basic Blocks Nodes of CFG Edges of CFG
Optimizations Building the CFG Composed of Basic Blocks Straight line code without any branches or merges of control flow Nodes of CFG Statements (basic blocks)/switches/merges Edges of CFG Possible control flow sequence

Symbolic Evaluation Assign each variable the bottom value initially
Optimizations Symbolic Evaluation Assign each variable the bottom value initially Propagate changes in variable values as statements are executed Based on the idea of Abstract Interpretation

Symbolic Evaluation Flow Functions Confluence Operation
Optimizations Symbolic Evaluation Flow Functions x := e = Confluence Operation join over all incoming edges

Symbolic Evaluation Flow Functions Confluence Operation
Optimizations Symbolic Evaluation Flow Functions x := e = ƒ Confluence Operation join over all incoming edges

The Dataflow analysis algorithm
Optimizations The Dataflow analysis algorithm Associate one state vector with each edge of CFG. Initialize all entries to Set all entries on outgoing edge from START to Evaluate the expression and update the output edge Continue till a fixed point is reached

Optimizations Example Evaluation

Termination Condition
Optimizations Termination Condition If each flow function ƒ is monotonic i.e. x ≤ y => ƒ (x) ≤ ƒ (y) And if the lattice is of finite height The dataflow algorithm terminates

Other Optimizations constant propagation available expression
All Paths Any Path constant propagation available expression reaching definitions busy expressions live variables Forward Flow Backward Flow

Making the problem easier
Overview Making the problem easier Task of proving compiler correct Automatic Theorem Prover

Overview Making the problem easier Task of proving optimizer correct Only prove optimizer correct. Trust front-end and code-generator. Automatic Theorem Prover

Overview Making the problem easier Task of proving optimizer correct Write optimizations in Cobalt, a domain-specific language. Automatic Theorem Prover

Overview Making the problem easier Task of proving optimizer correct Write optimizations in Cobalt, a domain-specific language. Separate correctness from profitability. Automatic Theorem Prover

Overview Making the problem easier Task of proving optimizer correct Write optimizations in Cobalt, a domain-specific language. Separate correctness from profitability. Factor out the hard and common parts of the proof, and prove them once by hand. Automatic Theorem Prover

The Design Overview Interpreter Input Output Cobalt Program
Cobalt is a domain specific language. The input is a program in a C-like language that has the usual features of an imperative language. Input Output Cobalt Program

Overview The Design

The Compiler Overview Front End Source Code 10011011 Back 00010100 End
if (…) { x := …; } else { y := …; } …; Front End Source Code Back End Binary Executable

Results Cobalt language Correctness checker for Cobalt opts
Overview Results Cobalt language realistic C-like IL, operates on a CFG implemented const prop and folding, branch folding, CSE, PRE, DAE, partial DAE, and simple forms of points-to analyses Correctness checker for Cobalt opts using the Simplify theorem prover Execution engine for Cobalt opts in the Whirlwind compiler

Overview Cobalt  Rhodium  ?

Caveats May not be able to express your opt Cobalt:
Overview Caveats May not be able to express your opt Cobalt: no interprocedural optimizations for now. optimizations that build complicated data structures may be difficult to express. A sound Cobalt optimization may be rejected by the correctness checker. Trusted computing base (TCB) includes: front-end and code-generator, execution engine, correctness checker, proofs done by hand once

Constant Prop (straight-line code)
Forward Optimizations Constant Prop (straight-line code) statement y := 5 y := 5 statements that don’t define y statement x := y x := y x := 5 REPLACE

Adding arbitrary control flow
Forward Optimizations Adding arbitrary control flow if statement y := 5 y := 5 y := 5 y := 5 is followed by statements that don’t define y until x := y x := 5 statement x := y REPLACE then transform statement to x := 5

Forward Optimizations
Constant prop in English if statement y := 5 is followed by statements that don’t define y until statement x := y then transform statement to x := 5

Forward Optimizations
Constant prop in Cobalt if statement y := 5 stmt(Y := C) boolean expressions evaluated at nodes in the CFG is followed by followed by statements that don’t define y ¬ mayDef(Y) until until statement x := y X := Y then X := C transform statement to x := 5 English version Cobalt version

Proving correctness automatically
Proving Optimizations Correct Proving correctness automatically y := 5 y := 5 y := 5 Witnessing region Invariant: y == 5 x := y x := 5

Constant prop revisited
Proving Optimizations Correct Constant prop revisited Ask a theorem prover to show: A statement satisfying stmt(Y := C) establishes Y == C A statement satisfying ¬mayDef(Y) maintains Y == C The statements X := Y and X := C have the same semantics in a program state satisfying Y == C stmt(Y := C) followed by ¬ mayDef(Y) until X := Y X := C with witness Y == C

Generalize to any forward optimization
Proving Optimizations Correct Generalize to any forward optimization Ask a theorem prover to show: A statement satisfying 1 establishes P A statement satisfying 2 maintains P The statements s and s’ have the same semantics in a program state satisfying P 1 followed by 2 until s s’ with witness We showed by hand once that these conditions imply correctness. P

Profitability heuristics
Optimization correct  safe to perform any subset of the matching transformations. So far, all transformations were also profitable. In some cases, many transformations are legal, but only a few are profitable.

The two pieces of an optimization
Profitability Heuristics The two pieces of an optimization Transformation pattern: defines which transformations are legal. 1 followed by 2 until s s’ with witness P filtered through choose Profitability heuristic: describes which of the legal transformations to actually perform. does not affect soundness. can be written in a language of the user’s choice. This way of factoring an optimization is crucial to our ability to prove optimizations sound automatically.

Profitability heuristic example: PRE
Profitability Heuristics Profitability heuristic example: PRE PRE as code duplication followed by CSE

Profitability Heuristics Profitability heuristic example: PRE PRE as code duplication followed by CSE a := ...; b := ...; if (...) { x := a + b; } else { ... } Code duplication x := a + b;

Profitability Heuristics Profitability heuristic example: PRE PRE as code duplication followed by CSE a := ...; b := ...; if (...) { x := a + b; } else { } x := Code duplication CSE self-assignment removal x := a + b; a + b; x;

Profitability Heuristics Profitability heuristic example: PRE Legal placements of x := a + b Profitable placement a := ...; b := ...; if (...) { x := a + b; } else { ... }

The Cobalt Language Operates on a Control Flow Graph A rewrite rule
Pure Analyses The Cobalt Language Operates on a Control Flow Graph A rewrite rule A guard to ensure appropriate conditions A predicate condition Filtered thru the choose function Pure analysis like pointer analysis. Verify properties such as no null pointer dereference

The Cobalt Language Pure analyses also possible Verify properties
For use by other transformations

Constant prop revisited (again)
Pure Analyses Constant prop revisited (again) stmt(Y := C) followed by ¬ mayDef(Y) until X := Y X := C with witness Y == C

mayDef in Cobalt followed by until with witness stmt(Y := C)
Pure Analyses mayDef in Cobalt stmt(Y := C) followed by ¬ mayDef(Y) until X := Y X := C with witness Y == C

mayDef in Cobalt followed by until with witness Very conservative!
Pure Analyses mayDef in Cobalt stmt(Y := C) followed by ¬ mayDef(Y) until X := Y X := C with witness Very conservative! Can we do better? Y == C

mayDef in Cobalt followed by until with witness stmt(Y := C)
Pure Analyses mayDef in Cobalt stmt(Y := C) followed by ¬ mayDef(Y) until X := Y X := C with witness Y == C

mayDef in Cobalt followed by until with witness
Pure Analyses mayDef in Cobalt stmt(Y := C) followed by ¬ mayDef(Y) until X := Y X := C with witness mayPntTo is a pure analysis. It computes dataflow info, but performs no transformations. Y == C

mayPntTo in Cobalt followed by defines with witness stmt(decl X)
Pure Analyses mayPntTo in Cobalt decl X stmt(decl X) followed by ¬ stmt(... := &X) defines s addrNotTaken(X) with witness mayPntTo(X,Y) , ¬ addrNotTaken(Y) “no location in the store points to X”

Expressiveness of Cobalt
Concluding Remarks Expressiveness of Cobalt Constant propagation, folding Copy propagation Common Subexpression Elimination Branch Folding Partial Redundancy Elimination Loop invariant code motion Partial Dead Assignment Elimination

Future work Improving expressiveness Inferring the witness
Concluding Remarks Future work Improving expressiveness interprocedural optimizations one-to-many and many-to-many transformations Inferring the witness Generate specialized compiler binary from the Cobalt sources.

Summary and Conclusion
Concluding Remarks Summary and Conclusion Optimizations written in a domain-specific language can be proven correct automatically. The correctness checker found several subtle bugs in Cobalt optimizations. A good step towards proving compilers correct automatically.

Building “Correct” Compilers

Similar presentations

Presentation on theme: "Building “Correct” Compilers"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Building “Correct” Compilers

Similar presentations

Presentation on theme: "Building “Correct” Compilers"— Presentation transcript:

Similar presentations

About project

Feedback