Formal Compiler Correctness

• Formal compiler correctness is the mathematically grounded practice of using formal semantics, proof systems, and mechanized reasoning to verify that a compiler preserves its source program's behavior.
• It employs methods such as simulation diagrams, coinductive proofs, and refinement frameworks within proof assistants like Coq, Isabelle, and HOL4 to ensure semantic preservation.
• Practical applications include verified compilers like CompCert and CakeML, which enhance software trustworthiness in high-assurance and safety-critical systems.

Formal compiler correctness refers to the rigorous, mathematically grounded specification and verification of the relationship between a source programming language and its target representations (often executable code), typically through formal semantics, proof systems, and mechanized reasoning. The core objective is to guarantee that compiling a source program preserves its meaning and behavior, ensuring that the output code is correct by construction. This discipline is central to trustworthy software infrastructure, high-assurance systems, verified hardware synthesis, and critical application domains.

1. Theoretical Foundations and Definitions

Formal compiler correctness relies on the construction of semantics for both the source and target languages. Most commonly, the relationship is articulated as semantic preservation: given a source program $P$ and its compiled output $C = \mathsf{compile}(P)$, for all observable behaviors $\mathcal{B}$, the semantics of $P$ and $C$ coincide: $$\forall \mathcal{B}.~ \mathsf{sem}_\mathsf{src}(P, \mathcal{B}) \implies \mathsf{sem}_\mathsf{tgt}(C, \mathcal{B})$$ Semantic preservation may be instantiated as:

• Whole-program equivalence: all terminating behaviors, or all traces, are preserved.
• Refinement notions: target behaviors refine source, possibly allowing additional nondeterminism.
• Simulation relations: forward (target simulates source) or backward (source simulates target) simulation relations.
• Bisimulation: mutual simulation, often for concurrency or reactive systems.

The correctness statement is proved either for each compiler phase (compositional verification) or for the whole pipeline as a monolithic transformation.

2. Methodologies: Specification, Proof, and Mechanization

Current methodologies integrate formal semantics, proof systems, and mechanized proof assistants.

2.1. Language Semantics

• Denotational, operational, or axiomatic semantics are defined for source and target. Semantic artifacts may be encoded in a proof assistant (e.g., Coq, Isabelle, HOL4) to enable mechanized reasoning.

2.2. Compiler Implementation

• Compilers are often written in a language suitable for extraction, synthesis, or verification within proof assistants.
• Each transformation phase (e.g., parsing, optimization, code generation) is annotated with invariants and semantic-preservation lemmas.

2.3. Proof Techniques

• Simulation diagrams: Constructed between the operational steps of source and target, showing behavior preservation at every step.
• Coinductive proofs: Used for infinite-state or reactive systems (e.g., compilers for reactive/embedded code).
• Monotonicity & refinement frameworks: For modular proof reuse, particularly with optimizing transformations.

2.4. Mechanized Proofs

• End-to-end proofs mechanized in systems like Coq (as exemplified by CompCert, Vellvm, CakeML).
• Automation for phase-local reasoning, but often human-guided orchestration at system scale.
• Linked proof artifacts facilitating audit and re-validation with compiler evolution.

3. Formal Correctness Criteria and Granularity

Formal compiler correctness criteria can operate at several levels:

Level	Example Property	Tooling/Proof Context
Syntactic	Parser ambiguity, syntax error preservation	Formal grammar proofs
Type System	Type-preserving compilation (type soundness)	Typed IRs, proof assistants
Semantic (Function)	Functional semantics, trace preservation	Equivalence/Refinement proofs
Security/Side-Channel	Constant-time preservation, non-interference	Information-flow logics
Concurrency/Reactive	Event-trace or temporal properties	Bisimulation, LTL-integration

In practice, the choice of property reflects the application domain. For verified cryptography or critical systems, strict equivalence up to external I/O may be enforced; for more permissive optimizations, trace containment/refinement is typical.

4. Compositionality and Modular Verification

Modern compiler infrastructure decomposes the pipeline into composable passes, each with local correctness lemmas. Compositionality is crucial to scalability:

• Phase-local proofs: Each pass $T_i$ is proved to preserve a simulation/invariant.
• Contextual equivalence: For open programs (e.g., modules, objects), correctness must quantify over all admissible contexts.
• Vertical composition: Proofs are chained using transitivity of the simulation relation.

Approaches such as proof-carrying code, proof-producing transforms, and verified linking increase modularity, enabling separate compilation and linking correctness.

5. Case Studies and Recent Results

Several major systems embody formal compiler correctness:

• CompCert: A fully verified, optimizing C compiler in Coq, proving semantic preservation from C to PowerPC/ARM assembly.
• CakeML: End-to-end verified ML compiler in HOL4, including a formally verified bootstrapping and I/O system.
• Vellvm: Formal semantics and verified passes for LLVM IR in Coq.
• Verified hardware synthesis: End-to-end proofs from high-level logic to gate-level circuits.

Recent research advances push toward:

• Verified JITs and dynamic compilation
• Verified macro systems and DSL compilers
• Scalable proof re-use for evolving compiler architectures
• Integration of formal verification with optimization search (see template‐guided superoptimization in “AccelOpt: A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization” (Zhang et al., 19 Nov 2025), which, while primarily focused on empirical kernel search, highlights the need for correctness-preserving transformations in LLM-driven compilation)

Empirical evidence confirms the reliability benefits: CompCert's compiled code exhibits fewer miscompilations compared to mainstream unverified compilers, as demonstrated through large-scale fuzz-testing under the strictest formal criteria.

6. Extensions: LLM-based and Agentic Compiler Self-Improvement

Recent developments introduce agentic/self-improving frameworks where LLM agents autonomously propose, self-evaluate, and distill optimization strategies (including low-level code transformations) while preserving correctness via automated test suite execution and in-context example memory (Zhang et al., 19 Nov 2025). Such systems close the loop by iteratively updating a memory of verified slow→fast transformations, yielding robust correctness even as the search space dynamically expands.

• The "optimization memory" in AccelOpt stores positive/negative slow-fast kernel pairs, appending only those passing correctness checks.
• The Profiler/Evaluator module in such systems always checks for functional correctness before performance evaluation, enforcing compiler-level correctness for every candidate transformation.

This approach incorporates formal correctness as a practical filter in self-improving code generation loops, with empirical results showing monotonic performance improvement with correctness guarantees (average peak throughput rising from 49%→61% and 45%→59% for distinct hardware, with no violations of kernel-level correctness) (Zhang et al., 19 Nov 2025).

7. Challenges and Future Directions

Key ongoing challenges in formal compiler correctness include:

• Scaling mechanized proofs for industrial-scale optimizing compilers and multi-language pipelines.
• Handling undefined behavior and non-determinism in real-world specifications.
• Formalizing correctness under resource constraints (e.g., concurrency, real-time, or memory hierarchies).
• Bridging with agentic, memory-driven, or self-improving systems, where correctness filtering must operate within an open-ended, continually evolving transformation space.
• Balancing optimization and correctness: As LLM-driven or beam search–based code optimization scales (as in “AccelOpt” (Zhang et al., 19 Nov 2025)), formal correctness filters and memory curation become central to avoid regressing safety or functionality.
• Integration with formal specification formats (Coq, HOL, SMT, property-based testing) for proof reuse and interoperability.

Formal compiler correctness thus constitutes the foundation of reliable compute infrastructure, with modern research extending both depth (proof sophistication, fine-grained properties) and breadth (self-improving, agentic, and LLM-driven compilation pipelines). The trend toward automated or self-improving approaches will further entrench correctness-preserving protocols at the core of evolving, adaptive compiler and code synthesis ecosystems.