🤖 AI

LLM Translation of Compiler Intermediate Representation

This paper introduces IRIS-14B, a specialized 14-billion-parameter Large Language Model that significantly outperforms existing state-of-the-art models by accurately translating GCC's GIMPLE intermediate representation to LLVM IR, thereby enabling seamless cross-toolchain interoperability within hybrid neuro-symbolic compiler architectures.

Original authors: Andrea Valenzuela Ramirez, Cristian Gutierrez-Gomez, Marta Barroso, Dario Garcia-Gasulla, Sara Royuela

Published 2026-05-12

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Andrea Valenzuela Ramirez, Cristian Gutierrez-Gomez, Marta Barroso, Dario Garcia-Gasulla, Sara Royuela

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of computer programming as a massive construction site. To build software, we need blueprints. In this industry, there are two giant construction companies: GCC and LLVM. They are the most famous teams, and they build almost everything from video games to operating systems.

However, these two teams speak different languages and use different blueprints.

GCC uses a blueprint language called GIMPLE. It's like a detailed, high-level architectural sketch that keeps the original design's structure intact.
LLVM uses a blueprint language called LLVM IR. It's more like a technical, low-level engineering diagram that breaks everything down into tiny, precise instructions.

The Problem: A Lost in Translation

For decades, if you wanted to use a tool from the GCC team to build something for the LLVM team, you were stuck. You couldn't just hand over the GIMPLE blueprint; the LLVM team wouldn't understand it.

Previously, engineers tried to build "human translators" (rule-based systems) to convert GIMPLE to LLVM. But these translators were like rigid dictionaries. If the GCC team changed a single word in their blueprint language, the dictionary broke, and the whole translation failed. Maintaining these dictionaries was a nightmare, so eventually, people stopped using them.

The Solution: The "Super-Translator" AI

This paper introduces a new solution: IRIS-14B. Think of IRIS as a brilliant, super-smart intern who has read millions of pairs of blueprints.

Instead of being taught a rigid set of rules (like "if you see a door, draw a window"), IRIS learned by observation. The researchers fed it thousands of examples where a GIMPLE blueprint was paired with its correct LLVM translation. Over time, IRIS learned the patterns and the logic of how to translate one language into the other, even when the structures looked very different.

What They Did

Built the Student: They took a large, pre-trained AI model (a general "smart" brain) and gave it a specialized education using their custom dataset of paired blueprints.
The Test: They put IRIS to the test against other famous AI models (some of which are 100 times larger). They gave IRIS GIMPLE blueprints and asked it to write the LLVM version.
The Result: IRIS won. Even though it was smaller than the other models, it translated the blueprints correctly 44% more often than the best general-purpose AI models. It understood the meaning of the code, not just the words.

Why This Matters (The "Magic" Use Cases)

The paper shows two cool tricks IRIS can do that were previously impossible or very hard:

The "Ada" Adapter: There is a programming language called Ada (used in aviation and defense) that GCC supports perfectly, but the LLVM team doesn't fully support yet. Using IRIS, you can take an Ada program written for GCC, translate its blueprint to LLVM, and suddenly, that program can run on LLVM's modern tools without rewriting a single line of the original code.
The "Modula-2" Revival: There is an old language called Modula-2 that GCC still supports, but LLVM has no native translator for it. IRIS acts as a bridge, allowing old Modula-2 code to be processed by modern LLVM tools, giving these legacy systems a new life.

The Catch

The paper notes a few limitations, like a translator who is great at short stories but struggles with a whole encyclopedia.

Context Limits: If a program is huge (thousands of lines long), the AI might get overwhelmed because it can only "read" a certain amount of text at once.
Complexity: The AI struggles a bit more with very complex structures, like specific types of data containers (structs) or heavy memory management, but it still does much better than the old rule-based methods.

The Big Picture

This paper doesn't claim that AI will replace human engineers or compilers. Instead, it proposes a hybrid team.

The traditional compilers (the old, reliable experts) still do the heavy lifting of optimization and final code generation.
The AI (IRIS) acts as a universal adapter. It sits in the middle, translating between the two different "dialects" of compiler blueprints so they can work together.

In short, the researchers built a bridge between two isolated islands of software technology, allowing them to share tools and resources without having to rebuild the islands themselves.

Technical Summary: LLM Translation of Compiler Intermediate Representation

Problem Statement

Modern software infrastructure relies heavily on two dominant, yet incompatible, compiler ecosystems: GCC and LLVM. While both utilize Intermediate Representations (IRs) to drive optimizations and code generation, their IRs—specifically GCC's GIMPLE and LLVM's LLVM IR—differ fundamentally in design philosophy, structure, and semantics.

Structural Differences: GIMPLE is statement-oriented and preserves high-level control structures, whereas LLVM IR is expression-oriented, lowering control flow into basic blocks, branches, and $\phi$ -nodes.
Semantic Differences: They diverge in memory models (virtual operands vs. explicit load/store), type system strictness, and exception handling.
The Barrier: These discrepancies create significant obstacles for cross-toolchain interaction, preventing the reuse of frontends, backends, and optimization pipelines across languages and ecosystems.
Limitations of Existing Solutions: Traditional rule-based translators (e.g., DragonEgg, Wyrm) have attempted to bridge this gap but suffer from high maintenance costs, brittleness to compiler version changes, and an inability to generalize beyond narrow program subsets.

Methodology

The paper proposes IRIS-14B, a data-driven approach using Large Language Models (LLMs) to learn the complex semantic mappings between GIMPLE and LLVM IR directly from paired examples, rather than relying on hand-crafted rules.

1. Model Architecture and Training

Base Model: The authors fine-tuned Qwen3-14B, a 14-billion-parameter decoder-only transformer, chosen for its manageable size and strong pre-training on code.
Training Data: Two curated datasets of paired GIMPLE and LLVM IR were constructed:
- TheStack-IRIS: Derived from 310,000 C code samples from GitHub, compiled to extract aligned IR pairs.
- GNU-IRIS: A dataset of 13,049 aligned function pairs extracted from GNU utilities, processed to fit within context limits.
Training Procedure: The model was trained on 1.4 billion tokens of paired IR data using the AdamW optimizer with a cosine scheduler. The training was conducted on 15 nodes with 4xH100 GPUs, taking approximately 35 hours.

2. Translation Pipeline

The proposed methodology integrates IRIS-14B into existing compiler toolchains without modifying the compilers themselves:

Input: A source code file is compiled by GCC to generate an unoptimized GIMPLE dump (via -fdump-tree-gimple).
Translation: The GIMPLE text is fed into IRIS-14B, which generates the corresponding LLVM IR.
Output: The generated LLVM IR is compiled by the LLVM toolchain to produce an executable.
This approach treats the translation as a text-to-text task, decoupling the model from compiler internals and allowing it to adapt to IR syntax changes without rewriting compiler passes.

Key Contributions

IRIS-14B: The first open-source LLM explicitly trained for IR-to-IR translation (GIMPLE to LLVM IR).
Novel Methodology: A framework for integrating LLMs as interoperability layers within hybrid neuro-symbolic compiler architectures, enabling cross-toolchain workflows without altering existing compiler passes.
Datasets: The release of TheStack-IRIS and GNU-IRIS (training sets) and ExeBench-IRIS and CodeForces-IRIS (evaluation sets), providing the first publicly available aligned GIMPLE-LLVM IR corpora.
Comprehensive Evaluation: A rigorous assessment pipeline measuring both syntactic correctness (compilation success) and functional equivalence (I/O test passing).

Results

The model was evaluated against state-of-the-art general-purpose and coding LLMs (ranging from 13B to 1,000B parameters) on two benchmarks: ExeBench-IRIS (real-world code) and CodeForces-IRIS (competitive programming).

Performance: IRIS-14B significantly outperformed all baselines.
- On CodeForces-IRIS, it achieved a 73.24% compilation success rate and 63.26% functional equivalence (I/O pass rate). This represents an improvement of up to 44 percentage points over the strongest baseline (gpt-oss-120b).
- On ExeBench-IRIS, it reached 86.89% compilation and 79.06% I/O correctness, surpassing the best competitor by over 6 percentage points.
Model Size vs. Performance: The results indicate that task-specific fine-tuning on paired IR data is more critical than model scale. A specialized 14B model outperformed general-purpose models with up to two orders of magnitude more parameters.
Error Analysis: The model struggles most with high-complexity code (longer than 50 lines, deep nesting) and specific constructs like struct usage, memory operations (malloc/free), and array writes. The presence of struct keywords increased failure rates by nearly 35%.
Data Source Impact: Training on diverse, real-world code (TheStack-IRIS) yielded significantly better results than training exclusively on competitive programming code (CodeForces-IRIS), highlighting the importance of heterogeneous data.

Significance and Claims

The paper claims that IRIS-14B demonstrates the viability of using LLMs to solve the long-standing problem of compiler interoperability.

Proof of Concept: It establishes that data-driven methods can overcome the limitations of rule-based translators, achieving high accuracy in translating between heterogeneous IRs.
Practical Application: The approach enables the compilation of legacy or GCC-specific code (e.g., Ada with Scalar_Storage_Order or Modula-2) using the LLVM toolchain, effectively bridging feature gaps without reimplementing frontends.
Future Role: The authors position IRIS-14B not as a replacement for traditional compilers, but as a complementary component in hybrid neuro-symbolic architectures. In this vision, deterministic compiler infrastructure handles standard compilation, while LLMs act as interoperability layers for cross-ecosystem translation and optimization cross-pollination.
Robustness: The model shows resilience to compiler version evolution; a model trained on older IR versions (GCC 11/LLVM 14) remained effective when tested on newer versions (GCC 15/LLVM 22), suggesting that core IR patterns remain stable enough for data-driven approaches.