Automated Soundness Proofs for Dataflow Analyses and Transformations via Local Rules Sorin Lerner* Todd Millstein** Erika Rice* Craig Chambers* * University.

Slides:



Advertisements
Similar presentations
Global Value Numbering using Random Interpretation Sumit Gulwani George C. Necula CS Department University of California, Berkeley.
Advertisements

Program Analysis using Random Interpretation Sumit Gulwani UC-Berkeley March 2005.
Copyright 2000 Cadence Design Systems. Permission is granted to reproduce without modification. Introduction An overview of formal methods for hardware.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
An Abstract Interpretation Framework for Refactoring P. Cousot, NYU, ENS, CNRS, INRIA R. Cousot, ENS, CNRS, INRIA F. Logozzo, M. Barnett, Microsoft Research.
Technology from seed Automatic Equivalence Checking of UF+IA Programs Nuno Lopes and José Monteiro.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Automated Refinement Checking of Concurrent Systems Sudipta Kundu, Sorin Lerner, Rajesh Gupta Department of Computer Science and Engineering, University.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
1 Mechanical Verification of Timed Automata Myla Archer and Constance Heitmeyer Presented by Rasa Bonyadlou 24 October 2002.
Pointer Analysis Lecture 2 G. Ramalingam Microsoft Research, India.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
Technology from seed Weakest Precondition Synthesis for Compiler Optimizations Nuno Lopes and José Monteiro.
Technology from seed Automatic Synthesis of Weakest Preconditions for Compiler Optimizations Nuno Lopes Advisor: José Monteiro.
The Design and Implementation of a Certifying Compiler [Necula, Lee] A Certifying Compiler for Java [Necula, Lee et al] David W. Hill CSCI
An Integration of Program Analysis and Automated Theorem Proving Bill J. Ellis & Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt.
Discovering Affine Equalities Using Random Interpretation Sumit Gulwani George Necula EECS Department University of California, Berkeley.
Plan for today Proof-system search ( ` ) Interpretation search ( ² ) Quantifiers Equality Decision procedures Induction Cross-cutting aspectsMain search.
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Proof-system search ( ` ) Interpretation search ( ² ) Main search strategy DPLL Backtracking Incremental SAT Natural deduction Sequents Resolution Main.
Automatically Proving the Correctness of Compiler Optimizations Sorin Lerner Todd Millstein Craig Chambers University of Washington.
Correctness. Until now We’ve seen how to define dataflow analyses How do we know our analyses are correct? We could reason about each individual analysis.
Advanced Compilers CSE 231 Instructor: Sorin Lerner.
Administrative info Subscribe to the class mailing list –instructions are on the class web page, which is accessible from my home page, which is accessible.
Advanced Compilers CSE 231 Instructor: Sorin Lerner.
Program analysis Mooly Sagiv html://
X := 11; if (x == 11) { DoSomething(); } else { DoSomethingElse(); x := x + 1; } y := x; // value of y? Phase ordering problem Optimizations can interact.
Another example p := &x; *p := 5 y := x + 1;. Another example p := &x; *p := 5 y := x + 1; x := 5; *p := 3 y := x + 1; ???
Software Reliability Methods Sorin Lerner. Software reliability methods: issues What are the issues?
Validating High-Level Synthesis Sudipta Kundu, Sorin Lerner, Rajesh Gupta Department of Computer Science and Engineering, University of California, San.
Advanced Compilers CSE 231 Instructor: Sorin Lerner.
A Type System for Expressive Security Policies David Walker Cornell University.
From last time S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t.
From last lecture x := y op z in out F x := y op z (in) = in [ x ! in(y) op in(z) ] where a op b =
ESP [Das et al PLDI 2002] Interface usage rules in documentation –Order of operations, data access –Resource management –Incomplete, wordy, not checked.
Overview of program analysis Mooly Sagiv html://
Provably Correct Compilers (Part 2) Nazrul Alam and Krishnaprasad Vikram April 21, 2005.
Composing Dataflow Analyses and Transformations Sorin Lerner (University of Washington) David Grove (IBM T.J. Watson) Craig Chambers (University of Washington)
Pointer analysis. Flow insensitive loss of precision S1: l := new Cons p := l S2: t := new Cons *p := t p := t l t S1 p S2 l t S1 p S2 l t S1 p S2 l t.
Automatically Checking the Correctness of Program Analyses and Transformations.
Abstract Interpretation (Cousot, Cousot 1977) also known as Data-Flow Analysis.
Have Your Verified Compiler And Extend It Too Zachary Tatlock Sorin Lerner UC San Diego.
Introduction to Our Research on Certifying Compiler Zhaopeng Li (In Chinese: 李兆鹏 ) Certifying Compiler Group USTC-Yale Joint.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
Report on Project CComp Zhaopeng Li Joint work with Prof. Yiyun Chen, Zhong Zhuang, Simin Yang, Dawei Fan, Zhenting Zhang Software Security Lab., USTC,
Type Systems CS Definitions Program analysis Discovering facts about programs. Dynamic analysis Program analysis by using program executions.
University of Paderborn Software Engineering Group Prof. Dr. Wilhelm Schäfer Towards Verified Model Transformations Holger Giese 1, Sabine Glesner 2, Johannes.
Pointer Analysis Lecture 2 G. Ramalingam Microsoft Research, India.
Certifying Intermediate Programming Zhaopeng Li
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Pointer Analysis Lecture 2 G. Ramalingam Microsoft Research, India & K. V. Raghavan.
Program Representations. Representing programs Goals.
Random Interpretation Sumit Gulwani UC-Berkeley. 1 Program Analysis Applications in all aspects of software development, e.g. Program correctness Compiler.
PLC '06 Experience in Testing Compiler Optimizers Using Comparison Checking Masataka Sassa and Daijiro Sudo Dept. of Mathematical and Computing Sciences.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
FUNCTIONAL PROGRAMING AT WORK - HASKELL AND DOMAIN SPECIFIC LANGUAGES Dr. John Peterson Western State Colorado University.
Carnegie Mellon Vadim Zaliva, Franz Franchetti Carnegie Mellon University Department of Electrical and Computer Engineering Funded by the DARPA I2O HACMS.
Proving Optimizations Correct using Parameterized Program Equivalence University of California, San Diego Sudipta Kundu Zachary Tatlock Sorin Lerner.
Certifying and Synthesizing Membership Equational Proofs Patrick Lincoln (SRI) joint work with Steven Eker (SRI), Jose Meseguer (Urbana) and Grigore Rosu.
Credible Compilation With Pointers Martin Rinard and Darko Marinov Laboratory for Computer Science Massachusetts Institute of Technology.
Formal Methods: Model Checkers and Theorem Provers
Towards trustworthy refactoring in Erlang
(One-Path) Reachability Logic
Formal Methods in Software Engineering 1
Benjamin Goldberg Compiler Verification and Optimization
Reduction in End-User Shape Analysis
Compilers have many bugs
Fall Compiler Principles Lecture 10: Loop Optimizations
Advanced Compiler Design
Building “Correct” Compilers
Presentation transcript:

Automated Soundness Proofs for Dataflow Analyses and Transformations via Local Rules Sorin Lerner* Todd Millstein** Erika Rice* Craig Chambers* * University of Washington ** UCLA [graduating this year!]

A traditional compiler Parser Code Gen Compiler Opt

Using a domain specific language Parser Code Gen Compiler DSL Opt DSL Opt DSL Opt

Using a domain specific language Parser Code Gen Compiler DSL Execution engine DSL Opt DSL Opt DSL Opt

Checking correctness automatically Parser Code Gen Compiler DSL Execution engine DSL Opt DSL Opt DSL Opt

Checking correctness automatically Parser Code Gen Compiler DSL Execution engine Checker DSL Opt Checker DSL Opt Checker DSL Opt

Checker DSL Opt DSL Opt Checker DSL Opt Checking correctness automatically Checker

DSL Opt Checker DSL Opt Checker DSL Opt Checking correctness automatically Checker

DSL Opt Checking correctness automatically Checker

Checking correctness automatically VCGen Verification Condition (VC) Checker Automatic Theorem Prover Checker DSL Opt

Checking correctness automatically VCGen DSL Opt Checker Automatic Theorem Prover Verification Condition (VC)

Checking correctness automatically opt- independent Checker opt- specific Automatic Theorem Prover DSL Opt VCGen Lemma: VC implies correctness VC

Cobalt The Cobalt DSL is an instantiation of this architecture –An opt written in Cobalt is a rewrite rule triggered by a declarative global condition over the CFG Expressed and automatically proved the correctness of a variety of intraprocedural optimizations, including: –const prop and folding, branch folding, CSE, PRE, DAE, partial DAE [PLDI 03]

In this talk: the Rhodium DSL Increased expressiveness –New model for expressing opts: local propagation rules with explicit dataflow facts –Heap summaries –Infinite analysis domains –Flow-sensitive and -insensitive –Intraprocedural and interprocedural Some Rhodium opts not expressible in Cobalt: –Arithmetic invariant detection, integer range analysis, loop-induction-variable strength reduction, Andersen's may-point-to analysis with allocation-site summaries

Outline Overview Rhodium by example Checking correctness automatically Future work, related work and conclusion

MustPointTo analysis c := a a := &b *c := d cd ab cd c ab

MustPointTo info in Rhodium c := a a := &b *c := d mustPointTo ( a, b ) mustPointTo ( c, d ) cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, b )

MustPointTo info in Rhodium c := a a := &b *c := d mustPointTo ( a, b ) mustPointTo ( c, d ) cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, b ) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b )

MustPointTo info in Rhodium define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b )

Propagating facts c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) define fact mustPointTo(X:Var,Y:Var)

if currStmt = [X := &Y] then Propagating facts define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) if currStmt = [X := &Y] then a := &b mustPointTo ( a, b )

if currStmt = [X := &Y] then Propagating facts define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b )

if currStmt = [X := &Y] then Propagating facts if Æ currStmt = [Z := &W] Æ X  Z then define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) if Æ currStmt = [Z := &W] Æ X  Z then a := &b mustPointTo ( c, d )

if currStmt = [X := &Y] then Propagating facts if Æ currStmt = [Z := &W] Æ X  Z then define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) if Æ currStmt = [Z := X] then c := a mustPointTo ( a, b ) mustPointTo ( c, b )

if currStmt = [X := &Y] then Propagating facts if Æ currStmt = [Z := &W] Æ X  Z then define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) if Æ currStmt = [Z := X] then

if currStmt = [X := &Y] then Transformations if Æ currStmt = [Z := &W] Æ X  Z then define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) if Æ currStmt = [Z := X] then

*c := d Transformations define fact mustPointTo(X:Var,Y:Var) c := a a := &b *c := d cd ab cd c ab mustPointTo ( a, b ) mustPointTo ( c, d ) mustPointTo ( a, b ) mustPointTo ( c, b ) if Æ currStmt = [*X := Z] then transform to [Y := Z] mustPointTo ( c, b ) b := d

Semantics of a Rhodium opt Run all the propagations rules using optimistic iterative analysis starting with complete set of facts until the best fixed point is reached Then run all transformation rules For better precision, combine analyses and transformations using our previous composition framework [POPL 02]

More in Rhodium (see paper for details) Mixing facts Heap summaries MayPointTo analysis via MustNotPointTo Infinite domains Flow-sensitive and -insensitive Intraprocedural and interprocedural

Outline Overview Rhodium by example Checking correctness automatically Future work, related work and conclusion

Rhodium correctness checker Automatic theorem prover Checker opt- independent VCGen VC Lemma: VC ) correctness Rhodium optimization

Rhodium correctness checker Automatic theorem prover Checker opt- independent VCGen Rhodium optimization define fact … if … then transform … if … then … VC Lemma: VC ) correctness

Rhodium correctness checker Automatic theorem prover IL semantics axioms Rhodium optimization Checker opt- independent Lemma: VC ) correctness define fact … if … then transform … if … then … VCGen Local VC Lemma: Local VCs ) correctness

Local correctness of prop. rules define fact mustPointTo(X:Var,Y:Var) Z := X mustPointTo ( X, Y ) mustPointTo ( Z, Y ) currStmt = [Z := X] then if Æ

define fact mustPointTo(X:Var,Y:Var) define fact mustPointTo(X:Var,Y:Var) with meaning « X == &Y ¬ Local correctness of prop. rules currStmt = [Z := X] then mustPointTo ( X, Y ) mustPointTo ( Z, Y ) Z := X     XY  in  out ZY ? Local VC sent to ATP: if Æ then « Z == &Y ¬ (  out ) if « X == &Y ¬ (  in ) Æ Z := X  in  out

Local correctness of trans. rules define fact mustPointTo(X:Var,Y:Var) if Æ currStmt = [*X := Z] then transform to [Y := Z] with meaning « X == &Y ¬ then if « X == &Y ¬ (  in ) Æ *X := Z  in  out Y := Z  in  out mustPointTo ( X, Y ) *X := Z XY  in  out ? Y := Z XY  in  out Y := Z Local VC sent to ATP:

More on correctness (see paper for details) Heap summaries Separating profitability from correctness Theorem stating soundness of the framework for creating interprocedural and flow-insensitive analyses

Outline Overview Rhodium by example Checking correctness automatically Future work, related work and conclusion

Current and future work Backward optimizations Infer rules from just the dataflow fact declarations and their meanings Debugging Efficient execution engine

Some related work Proving correctness by hand –Abstract interpretation [Cousot and Cousot 77, 79] –Partial equivalence relations [Benton 04] –Temporal logic [Lacey et al. 02] Proving correctness with interactive theorem prover –Using Coq proof assistant [Cachera et al. 04] Testing correctness one compilation at a time –Translation validation [Pnueli et al. 98, Necula 00] –Credible compilation [Rinard 99] Execution engines –Incremental execution of transformations [Sittampalam et al. 04] –Running opts specified with temporal logic [Steffen 91]

Conclusion Local rules in Rhodium are more expressive than Cobalt’s global condition The correctness checker found subtle bugs in our Rhodium opts Good step towards pushing more of the burden of writing compilers on to the computer