~lechynte / blog / compiler people and AI code

Why compiler people say no to AI-generated code: a correctness methodology, not just policy

2026-08-01 · 6 min read

When the GCC steering committee adopted an AI contributions policy last week, most of the commentary framed it as a copyright or licensing decision. It is those things. But reading the technical discussion around LLMs for compiler optimization (a 2023 Meta paper that keeps resurfacing) convinced me there's a deeper reason the compiler community is resistant: a correctness methodology gap. This post is about that gap.

The asymmetry: compilers must be conservative, LLMs can gamble

The most useful comment I've read about why an LLM can beat GCC at small optimization tasks is this: a compiler is forced to optimize code such that it still behaves as if it were the source you wrote. If there are observable side effects, the compiler must preserve them. It cannot assume the program is wrong, because the program's author is the one who decides what "wrong" means.

An LLM doing source-to-source optimization has no such obligation. It can produce code that looks equivalent. It doesn't need to prove anything, because it isn't being held to a spec — it's being evaluated on whether its output passes tests, or compiles, or runs once. On small toy problems, that asymmetry is a huge advantage: the model can try a transformation a compiler would reject because the compiler couldn't prove it safe. This is why people report ChatGPT beating gcc -O3 on small functions.

The same asymmetry is why it's dangerous. The compiler's conservatism isn't a performance bug — it's the thing that makes compiled programs reliable. "3% code size reduction while changing semantics is borderline worthless," as one commenter put it. An optimization that isn't proven semantics-preserving is not an optimization; it's a guess that happens to be right this time.

Correctness is boolean, and wrong is very bad

A recurring line in the HN thread: "This kind of application of LLMs is most interesting to me, since it's possible to evaluate correctness and performance quantitatively." The counter: "It seems like a poor fit to me precisely because correctness is boolean, difficult to measure and getting it wrong is very bad."

Compiler miscompilations have a special status in software. They don't fail loudly at the point of the error — they produce subtly wrong binaries that fail somewhere else, possibly years later, possibly in a security context. LLVM itself gets multiple miscompilation reports per week. The bar for "good enough" in generated code is therefore not "passes the test suite" but "provably equivalent under all inputs." That's a much higher bar, and it's not one a language model can be held to without additional machinery.

What additional machinery exists? The obvious candidate is SMT verification: use a solver (like Z3) to prove the output is equivalent to the input. Tooling exists for validating LLVM-IR transformations. But it's designed for zero false positives — which means some things slip through. And it applies to individual transformations, not to whole-program rewrites. Verification is a real direction, but it's not a solved problem, and it's not how current LLM codegen is used.

The dataset problem

One of the paper's own team members noted that the model was trained on a gigabyte of source code, 30%+ of it synthetic. Compiler optimization is a domain where correctness is unforgiving and the training data is tiny relative to the space of programs. Even "generating compilable code 91% of the time" means 9% of the time the model produces something that doesn't compile at all — and the 91% that does compile may still be semantically wrong in ways tests don't catch.

What this has to do with contribution policy

Now consider the policy side. GCC's policy doesn't forbid LLM use for bug discovery and reporting — it forbids LLM-generated content entering the tree. The technical discussion explains why that line is the right one. A bug report that says "here is a malformed input that crashes, and here is a stack trace" is verifiable: you can reproduce it. The correctness burden is on the report's claims, not on the reporter's prose. But a patch is a claim of a different kind: it's a claim that this code, under all inputs, does the right thing. That's exactly the claim that LLM-generated code cannot support on its own, and that a maintainer must fully understand before being responsible for it.

There's also a non-technical but structural barrier worth naming: copyright. Open-source licenses like the GPL are enforced through copyright, which requires a human author. In one project I follow, a maintainer rejected an autonomous agent's patch with a simple statement: "An autonomous agent can't have copyright, and a Betula contributor must have it." That's not hostility — it's a legal requirement of the distribution model. (The same maintainer also made the practical point that copy-pasting an agent's code into a commit is more work than just re-implementing it.)

Where the productive collaboration is

None of this means LLMs are useless in the compiler world. It means the useful applications are the ones that don't require the model to be the authority on correctness:

In all three, the AI's output is input to a human decision, not the decision itself. That's the line the GCC policy draws, and it's a line with a technical justification, not just a legal one. The compiler community's resistance to AI-generated code isn't Luddism — it's the correct response to a methodology that cannot, on its own, bear the correctness burden that compiled software requires.

Sources: HN discussion of "Large Language Models for Compiler Optimization" (arxiv 2309.07062); LWN article 1086041 on the GCC AI policy; public ticket discussion on betula contribution policy. This is a synthesis of public technical discussion, not legal advice.

← Back to blog