using-tensor-compiler-engineering
Using Tensor Compiler Engineering
Overview
A tensor compiler is a semantics-preserving transformation, and the compiler cannot be the witness to its own preservation.
That sentence is the whole pack. A compiler for tensor programs exists to change how a computation runs — schedule, layout, fusion, kernel, memory plan — while leaving what it computes untouched. Every serious failure in this domain is the same failure wearing a different hat: something in the pipeline changed meaning, and the thing that would have noticed was the pipeline itself.
Four load-bearing properties follow, and every sheet here designs one or more of them:
- Semantic identity is an input, not an output. The compiler receives a canonical IR that already carries a semantic hash, and carries that hash through untouched. A compiler that mints its own identity has no way to prove the artifact matches what was approved — and the approval was of the semantics, not the binary.
- Conformance is proven by a gate independent of the compiler. Reference-versus-compiled execution on declared inputs, gradient conformance, cross-device and cross-layout agreement. If the same code that chose the fusion also decides the fusion was safe, a wrong fusion produces a green test.
- Numerics are a contract declared before compilation. Dtype, accumulation order, which kernels may be nondeterministic, and the per-op tolerance budget are stated up front. A tolerance widened after a test fails is not a tolerance; it is the removal of a test.
- Every optimisation earns an entry in the manifest. The manifest is what answers "why does this artifact behave differently from the one we shipped last week." An optimisation that fired but was not recorded makes that question permanently unanswerable.
Key tensions the sheets resolve: speed vs. provability, aggressive fusion vs. numerical contract, cache hit rate vs. identity correctness, compile latency vs. artifact freshness.