gyre

Gyre is a compiler IR designed as a practical "linguistic switchbox", or UNCOL.

Gyre is not particularly innovative, aiming instead to consolidate various existing techniques under a unified design. It's a graph-based IR, heavily influenced by Click's sea of nodes, although we take a more functional approach to SSA form by mixing Extended Basic Blocks with Thorin-style-CPS. Explicit concurrency comes with the addition of a standard memory consistency model and a message-passing mechanism from the join calculus. Several other features are "mashed up" in Gyre's design, coming from an extensive survey on compilers, portable IRs and the UNCOL solution to the "compiler construction problem".

"The language designer should be familiar with many alternative features designed by others ... One thing he should not do is to include untried ideas of his own. His task is consolidation, not innovation." - Tony Hoare, 1989
More...

Modules

graph
module gyre.graph

Program construction and manipulation API.

mnemonics
module gyre.mnemonics

Syntax sugar for our graph API.

nodes
module gyre.nodes

Structure and interpretation of Gyre nodes.

Detailed Description

Click here for more information on the IR's structure (albeit mixed with implementation details).

Design Principles

  • Expressivity: The IR must be able to represent, up to some level of detail, the essential properties of any program. Software which is not portable is also of interest, even if only to indicate where and how it uses machine-specific constructs and assumptions, or when compiling it to a compatible architecture (something which ought to be supported).
  • Efficiency: The IL format should be fast to decode and validate. At the same time, the IR itself must not introduce unreasonable costs to code transformations, nor impose additional restrictions (unnecessary from a logical standpoint) to its programs.
  • Progressivity: An optimizing compiler should prefer to retain, rather than recover, in- formation about a program. Premature lowering decreases optimization potential, so the IR must be able to preserve "high-level" structure for as long as it is desirable to do so.
  • Parsimony: The IR must not expand uncontrollably to accommodate new languages or machines. Instead, it ought to contain a well-defined core which is simple, yet expressive.
  • Extensibility: The IL should be amenable to extensions, both from users and to its own specification. These must be clearly signaled (possibly at different levels of program granularity) for the sake of compatibility. This principle complements the previous one.