Reference. Deriving efficient program transformations from rewrite rules

An efficient optimizing compiler can perform many cascading rewrites in a single pass, using auxiliary data structures such as variable binding maps, delayed substitutions, and occurrence counts. Such optimizers often perform transformations according to relatively simple rewrite rules, but the subtle interactions between the data structures needed for efficiency make them tricky to write and trickier to prove correct. We present a system for semi-automatically deriving both an efficient program transformation and its correctness proof from a list of rewrite rules and specifications of the auxiliary data structures it requires. Dependent types ensure that the holes left behind by our system (for the user to fill in) are filled in correctly, allowing the user low-level control over the implementation without having to worry about getting it wrong. We implemented our system in Coq (though it could be implemented in other logics as well), and used it to write optimization passes that perform uncurrying, inlining, dead code elimination, and static evaluation of case expressions and record projections. The generated implementations are sometimes faster, and at most 40% slower, than hand-written counterparts on a small set of benchmarks; in some cases, they require significantly less code to write and prove correct.

Cite

Cite as @li-2021-deriving (helia, typst) · \cite{li-2021-deriving} (LaTeX)
BibTeX
bibtex · 1 line
@article{li-2021-deriving, title={Deriving efficient program transformations from rewrite rules}, volume={5}, ISSN={2475-1421}, url={http://dx.doi.org/10.1145/3473579}, DOI={10.1145/3473579}, number={ICFP}, journal={Proceedings of the ACM on Programming Languages}, publisher={Association for Computing Machinery (ACM)}, author={Li, John M. and Appel, Andrew W.}, year={2021}, month=Aug, pages={1–29} }
hayagriva YAML (typst)
yaml · 18 lines
li-2021-deriving:
  type: article
  title: Deriving efficient program transformations from rewrite rules
  author:
  - Li, John M.
  - Appel, Andrew W.
  date: 2021-08
  page-range: 1-29
  url: http://dx.doi.org/10.1145/3473579
  serial-number:
    doi: 10.1145/3473579
    issn: 2475-1421
  parent:
    type: periodical
    title: Proceedings of the ACM on Programming Languages
    publisher: Association for Computing Machinery (ACM)
    issue: ICFP
    volume: 5
Cites 33 works (2 here)
With notes (2)

CakeML: A verified implementation of ML kumar_cakeml_2014

We have developed and mechanically verified an ML system called CakeML, which supports a substantial subset of Standard ML. CakeML is implemented as an interactive read-eval-print loop (REPL) in x86-64 machine code. Our correctness theorem ensures that this REPL implementation prints only those results permitted by the semantics of CakeML. Our verification effort touches on a breadth of topics including lexing, parsing, type checking, incremental and dynamic compilation, garbage collection, arbitraryprecision arithmetic, and compiler bootstrapping.
PDF · DOI · pldb

Finding and Understanding Bugs in C Compilers yangFindingUnderstandingBugs

Compilers should be correct. To improve the quality of C compilers, we created Csmith, a randomized test-case generation tool, and spent three years using it to find compiler bugs. During this period we reported more than 325 previously unknown bugs to compiler developers. Every compiler we tested was found to crash and also to silently generate wrong code when presented with valid input. In this paper we present our compiler-testing tool and the results of our bug-hunting study. Our first contribution is to advance the state of the art in compiler testing. Unlike previous tools, Csmith generates programs that cover a large subset of C while avoiding the undefined and unspecified behaviors that would destroy its ability to automatically find wrong-code bugs. Our second contribution is a collection of qualitative and quantitative results about the bugs we have found in open-source C compilers.
PDF · DOI · pldb
External (31)
li-2021-deriving reference entries/refs/li-2021-deriving/li-2021-deriving.hel