MELT - a Translated Domain Specific Language Embedded in the GCC Compiler

The GCC free compiler is a very large software, compiling source in several languages for many targets on various systems. It can be extended by plugins, which may take advantage of its power to provide extra specific functionality (warnings, optimizations, source refactoring or navigation) by processing various GCC internal representations (Gimple, Tree, …). Writing plugins in C is a complex and time-consuming task, but customizing GCC by using an existing scripting language inside is impractical. We describe MELT, a specific Lisp-like DSL which fits well into existing GCC technology and offers high-level features (functional, object or reflexive programming, pattern matching). MELT is translated to C fitted for GCC internals and provides various features to facilitate this. This work shows that even huge, legacy, software can be a posteriori extended by specifically tailored and translated high-level DSLs.

💡 Research Summary

The paper presents MELT, a Lisp‑style domain‑specific language (DSL) designed to extend the GNU Compiler Collection (GCC) through high‑level plugins. GCC is a massive, evolving code base (over 4 M lines of C code) that supports many front‑ends, internal representations (Tree, Gimple, RTL) and a rich set of optimization passes. Writing plugins directly in C is difficult, and embedding existing scripting languages (Python, Lua, OCaml, etc.) is impractical because of mismatched garbage collectors, a huge and unstable C‑centric API, extensive use of macros, and the need for fast low‑level access to internal data structures.

MELT addresses these challenges by providing a DSL that is translated into C code conforming to GCC’s coding conventions. The translation pipeline consists of a reader that builds S‑expressions, macro expansion, normalization (introducing temporaries), and code generation that emits C source files. These generated files are then compiled with the normal GCC toolchain, producing shared objects that are loaded as plugins. The MELT runtime, built on top of GCC’s own garbage collector (Gg‑c), adds a generational copying collector for MELT values (lists, tuples, closures, objects) because the existing collector is insufficient for the high allocation rate typical of functional code.

Key technical contributions include:

1. GCC‑aware code generation – MELT automatically emits GTY‑annotated structures, uses GCC’s iterator macros, and respects the mixture of functions and macros in the GCC API, eliminating the need for hand‑written glue code.
2. Hybrid type system – MELT values are dynamically typed, yet the language can directly manipulate raw GCC objects (gimple, tree, edge, etc.), enabling seamless interoperation.
3. Pattern‑matching engine – A powerful pattern matcher lets developers declaratively traverse and transform internal GCC representations, essential for tasks such as detecting specific function calls, performing loop optimizations, or generating OpenCL kernels.
4. Plugin architecture – The melt.so plugin loads MELT modules (e.g., warmelt*.so, xtramelt*.so) at runtime. Users invoke GCC with -fplugin=melt -fplugin-arg-melt-mode=... to select a mode, which registers a new GCC pass written in MELT. Example passes include simple warnings/optimizations, Gimple‑to‑C translation, and an experimental OpenCL code generator.
5. Performance considerations – Translation from MELT source to C is fast (≈1 s for a 6.5 KLOC file), while the dominant cost is compiling the generated C code (≈30 s on a single core). The generated C code runs with the same performance as hand‑written plugins because it is compiled by GCC itself.

The authors report that MELT has already been used for several prototype extensions, demonstrating its practicality. They also discuss the bootstrapping process: the MELT translator itself is written in MELT, compiled to C, and then used to translate other MELT programs.

In conclusion, MELT shows that a large, legacy system like GCC can be retro‑fitted with a high‑level, translated DSL, achieving both developer productivity and runtime efficiency. The approach sidesteps the need for embedding full interpreters, leverages existing GCC infrastructure, and opens the door for a richer ecosystem of GCC plugins written in a more expressive language. Future work includes expanding automatic bindings for more GCC APIs, improving the pattern‑matching compiler, and scaling the ecosystem to larger, production‑grade analyses and transformations.