HEIR: Homomorphic Encryption IR Framework

• HEIR is a multi-level, MLIR-based intermediate representation for homomorphic encryption that integrates diverse HE schemes and optimized compilation passes.
• It is organized into abstraction layers—from secret annotation to low-level polynomial and RNS arithmetic—enabling consistent optimizations and cross-scheme benchmarking.
• HEIR facilitates compilation pipelines for scalar and vector HE, providing reusable passes and backend targets for libraries and hardware accelerators.

Homomorphic Encryption Intermediate Representation (HEIR) is an MLIR-based compiler framework for homomorphic encryption (HE) that is designed as a multi-level, scheme-spanning infrastructure rather than as a single monolithic intermediate language. Its stated aim is to support all mainstream HE techniques, integrate with major software libraries and hardware accelerators, and provide a common substrate for optimization, benchmarking, and deployment across scalar and vector HE workflows (Ali et al., 14 Aug 2025). In practice, HEIR is organized as a family of abstraction layers that range from secret-annotated source computations to scheme dialects, low-level polynomial and RNS arithmetic, library APIs, and hardware-specific targets, with the explicit goal of making HE compilation techniques reusable and comparable within one system (Ali et al., 14 Aug 2025).

1. Motivation and problem setting

HE compilation is unusually difficult because correctness, security, and performance are entangled. The underlying schemes impose constraints from noise growth, ciphertext management, packing and layout, bootstrapping, and parameter selection, while the practical operator sets differ sharply between scalar HE and vector HE. The HEIR paper distinguishes two broad execution models: scalar HE, exemplified by DM and CGGI, where ciphertexts encrypt one scalar or bit-like value and often rely on programmable bootstrapping and lookup tables; and vector HE, exemplified by BGV, BFV, and CKKS, where ciphertexts encrypt vectors of size $2^{10}$ to $2^{17}$ and expose elementwise arithmetic plus cyclic rotations (Ali et al., 14 Aug 2025). The older HE survey presents the same landscape in a different vocabulary—PHE, SWHE, leveled FHE, and FHE—and makes explicit that depth, noise, key material, modulus management, and bootstrapping are inherent program properties rather than incidental runtime details (Acar et al., 2017).

HEIR was introduced against a background in which prior compilers were often tied to a single scheme, a single backend library, one optimization family, or a narrow application class. The HEIR paper names synthesis-heavy systems such as Google Transpiler and Porcupine, loop-unrolling-oriented systems such as HECO and HECATE, and partial-stack systems such as HeaNN-mlir and Cinnamon as examples of this fragmentation (Ali et al., 14 Aug 2025). A central design consequence is that HEIR is not merely a frontend or a backend wrapper; it is intended as a shared compilation substrate that can carry computations through multiple abstraction levels until the appropriate scheme, management policy, and target backend have been chosen.

2. Layered architecture and dialect hierarchy

HEIR’s most distinctive technical feature is its explicit multi-level organization within MLIR. MLIR is used because HE compilation naturally spans multiple semantic levels: ordinary source computation, secret computation, scheme-agnostic HE structure, scheme-specific operations, low-level polynomial and RNS arithmetic, and finally library or hardware APIs (Ali et al., 14 Aug 2025).

Layer	Dialects or examples	Function
Secret arithmetic	secret	Marks secret values while preserving compatibility with ordinary MLIR transformations
Scheme-agnostic HE	comb, mgmt, tensor_ext	Represents Boolean/LUT structure, ciphertext management, and vector-HE register/layout structure
Scheme-specific HE	lwe, bgv, ckks, cggi	Encodes concrete scheme types and operations
Low-level implementation	random, mod_arith, rns, polynomial	Models sampling, modular arithmetic, RNS values, and polynomial quotient-ring arithmetic
Code generation	openfhe, lattigo, tfhe_rust, jaxite, pisa	Mirrors library APIs or hardware ISAs for source generation and accelerator targeting

At the top of the stack, the secret dialect preserves the original computation while marking secrecy explicitly. Its core wrapper type is secret.secret<T>, and it uses secret.generic with secret.yield so that ordinary MLIR-style transformations can still be applied before committing to ciphertext types (Ali et al., 14 Aug 2025). HEIR also includes SecretnessAnalysis, a dataflow analysis that distinguishes ciphertext-ciphertext, ciphertext-plaintext, and plaintext-plaintext computation so that plaintext-only work can be hoisted out of secret regions.

The next layer introduces HE-specific structure without yet fixing a concrete scheme. The comb dialect represents Boolean circuits and lookup tables, especially for scalar HE flows. The mgmt dialect represents management operations such as mod_reduce, relinearize, and bootstrap. The tensor_ext dialect captures the vector-HE “ciphertext register” model, including slot rotations, packing, and layout-sensitive tensor structure (Ali et al., 14 Aug 2025). This separation is important: management, Boolean synthesis, and packed-vector layout are treated as reusable compiler concerns rather than as ad hoc backend conventions.

Scheme-specific dialects then refine these abstractions. HEIR defines lwe for common LWE and RLWE concepts and adds scheme dialects for bgv, ckks, and cggi; BFV is implemented as a special case of BGV with different encoding parameters (Ali et al., 14 Aug 2025). Beneath them sit the random, mod_arith, rns, and polynomial dialects, which model the arithmetic needed for actual scheme implementation and low-level accelerator lowering. The polynomial dialect is particularly significant because it is used both for implementation-level quotient-ring arithmetic and for polynomial approximation via a static polynomial representation plus eval (Ali et al., 14 Aug 2025).

3. Frontends, backends, and compilation pipelines

HEIR addresses the full compilation stack rather than only the IR core. Its most developed frontend is Python. Users write Python functions with type annotations such as Secret[...] and tensor types like Tensor[1024, I16]; the frontend translates Python bytecode into the secret dialect, performs basic type inference, supports loops and control flow, and enforces restrictions such as loop bounds that do not depend on secret data (Ali et al., 14 Aug 2025). For supported backends, this frontend also handles code generation, compilation to machine code, and dynamic loading of generated shared libraries back into Python.

StableHLO support is described as partial. The intended path is StableHLO to linalg, then annotation of secret inputs, and then ordinary HEIR compilation. The paper also states that, in principle, any frontend that can lower to standard MLIR could target HEIR, and it names ClangIR for C++ and onnx-mlir for ONNX as possible future frontend routes (Ali et al., 14 Aug 2025).

At the output end, HEIR provides library-API dialects for OpenFHE, Lattigo, TFHE-rs, TFHE-rs Boolean, Jaxite, and Jaxite Word, and heir-translate emits C++, Go, Rust, or Python for those backends (Ali et al., 14 Aug 2025). It also includes hardware-specific exits such as pisa, which models the Polynomial Instruction Set Architecture used by Intel’s HERACLES accelerator.

Two detailed case studies illustrate how these layers are used. The mlir-to-cggi pipeline targets AES-128 transciphering: it removes data-dependent conditions, unrolls loops with static bounds, invokes Yosys for gate or LUT synthesis, lowers to cggi, and generates code for TFHE-rs on CPU, Belfort FPGA, or Jaxite on TPU (Ali et al., 14 Aug 2025). The mlir-to-ckks pipeline targets a matrix-vector multiplication with ReLU sequence: it replaces arith.maximumf with polynomial.eval, applies polynomial approximation and Paterson-Stockmeyer evaluation, selects layouts, chooses the Halevi-Shoup diagonal matrix-vector method, inserts management, runs parameter selection, and emits OpenFHE C++ code including EvalMult, EvalRotate, EvalAdd, EvalMultNoRelin, and Relinearize, along with client encryption and decryption functions (Ali et al., 14 Aug 2025).

4. Analyses, rewrites, and optimization repertoire

HEIR’s claim to generality depends on an unusually broad optimization layer. The framework inherits 237 built-in MLIR passes and adds 88 HEIR-specific passes plus additional canonicalization and folding patterns (Ali et al., 14 Aug 2025). These passes cover ciphertext management, parameter selection, layout search, polynomial approximation, if-conversion, circuit synthesis, parallelization, memory optimization, and debugging.

Management insertion is scheme-aware. HEIR defines secret-insert-mgmt-bgv, secret-insert-mgmt-bfv, and secret-insert-mgmt-ckks; for BGV and CKKS it inserts relinearization after each multiplication, inserts modulus switching before multiplications except the first, handles scale mismatches, and uses a greedy initial bootstrap placement for CKKS, while BFV receives relinearization without modulus switching (Ali et al., 14 Aug 2025). HEIR also includes optimize-relinearization, an ILP-based pass built with Google or-tools and SCIP and adapted from Paindavoine and Vialla’s optimal bootstrap-placement ILP.

Parameter selection is similarly scheme-specific. For BGV and BFV, HEIR incorporates several noise models, including two BGV models from Kim et al., a BGV model from Murphy et al., the BFV model of BMCM23, and the BGV model of MMLGA23 together with its BFV adaptation (Ali et al., 14 Aug 2025). BGV parameter selection analyzes maximal noise at each RNS level and chooses tight prime moduli to reset noise via modulus switching; BFV analyzes total noise growth and chooses a tight chain of 60-bit primes. CKKS support is less automatic: the current system requires user-provided message-range bounds for noise models and user-provided first-modulus and scaling-modulus information, although range analysis can warn when the first modulus may be too small (Ali et al., 14 Aug 2025).

Layout selection is formalized rather than treated as backend folklore. HEIR represents vector-HE packing by an MLIR quasi-affine map

$$(d_1,\dots,d_n)\to(e_1(d_1,\dots,d_n),\dots,e_m(d_1,\dots,d_n)),$$

where the $e_i$ may use affine expressions together with ceildiv, floordiv, and mod by integer literals (Ali et al., 14 Aug 2025). The pipeline then applies layout-propagation, layout-optimizer, and convert-to-ciphertext-semantics, while implement-shift-network realizes slot permutations using the graph-coloring approach of Vos-Vos-Erkin (Ali et al., 14 Aug 2025). This makes packing, conversion, and slot movement explicit optimization subjects rather than hidden properties of runtime kernels.

HEIR also includes higher-level restructurings required by HE semantics. convert-if-to-select converts conditionals into select-style multiplexing; convert-secret-for-to-static-for turns loops with secret-dependent bounds into loops with secret-independent bounds using user-provided static upper bounds (Ali et al., 14 Aug 2025). This is consistent with prior work arguing that ordinary runtime branching in HE must usually be transformed into arithmetic predication or masking rather than preserved as conventional control flow (Chialva et al., 2018).

Further passes cover polynomial approximation through the Carathéodory-Fejér method, lowering via Paterson-Stockmeyer, the operation-balancer adapted from EVA, the yosys-optimizer for scalar HE circuit synthesis, straight-line-vectorizer for throughput-oriented scheduling, alloc-to-inplace for reducing allocations, lwe-add-client-interface for generated client APIs, a plaintext backend for debugging, and insert-debug-handler-calls for post-operation introspection and noise-model validation (Ali et al., 14 Aug 2025). EVA’s graph-level depth balancing is explicitly reused here, which underscores HEIR’s role as a collector and recomposer of prior compiler ideas (Dathathri et al., 2019).

5. Relation to earlier HE compiler abstractions

HEIR emerged after several partial answers to the HE compilation problem. CHET and its Homomorphic Instruction Set Architecture (HISA) are particularly important because HISA was designed as a compact interface between compilers or runtimes and concrete FHE libraries, not as a full IR. CHET explicitly states that the unified portability layer should instead be an intermediate representation containing fixed-point datatypes and precision requirements, to be lowered to different targets and profile subsets; this suggests that HEIR occupies the layer that CHET identified as missing (Dathathri et al., 2018).

EVA moved closer to that missing layer. It presented a single vector-arithmetic representation used as source language, IR, and executable graph, with explicit insertion of Rescale, ModSwitch, and Relinearize, and it showed that retargeting CHET through EVA produced programs that were on average $5.3\times$ faster than CHET’s earlier backend path (Dathathri et al., 2019). HEIR generalizes this IR-centric view but extends it across scalar and vector HE, multiple schemes, multiple low-level arithmetic forms, and both library and hardware exits rather than centering on CKKS-style encrypted vector arithmetic alone.

nGraph-HE, by contrast, treated HE as another backend target of a generic deep-learning graph compiler. That strategy established the value of graph-level rewrites, packing decisions, and multiplicative-depth-aware lowering, but its IR remained the generic nGraph computational graph rather than a dedicated HE IR with first-class secrecy, scheme, scale, and low-level arithmetic layers (Boemer et al., 2018). Viaduct-HE made a different contribution: it showed that vectorization schedules and ciphertext layouts over array dimensions are themselves compiler objects. Its index-free traversal representation, schedule language, circuit IR, and loop-nest IR all anticipate the kind of layout-sensitive tensor abstractions that HEIR’s tensor_ext layer is meant to make reusable across backends (Recto et al., 2023).

The broader literature supplies two further lessons that HEIR appears designed to absorb. One is that alternate numeric encodings and Boolean-circuit lowerings are not backend-neutral; the stochastic-encoding study over TFHE showed that gate count, depth, bootstrapping policy, packing, and error all interact with representation choice, which suggests that an HE IR must make encoding and legality decisions explicit rather than hard-coding one arithmetic path (Hsiao et al., 2022). The other is that control flow in HE cannot usually be modeled as ordinary runtime branching; the conditionals literature argues for if-conversion, predication, and masking, and HEIR’s restructuring passes make exactly those transformations part of the compilation pipeline (Chialva et al., 2018).

6. Backend realism, hardware lowering, and low-level arithmetic

HEIR’s lower dialects are best understood in light of work that exposes the structure of backend execution. CiFlow shows that hybrid key switching in CKKS is not merely a monolithic primitive: it decomposes into digit decomposition, INTT, basis conversion, NTT, evaluation-key application, and reduction, and admits multiple legal dataflows—Max-Parallel, Digit-Centric, and Output-Centric—with materially different SRAM and bandwidth behavior (Neda et al., 2023). This is consistent with HEIR’s decision to include low-level rns, polynomial, and hardware-exit dialects rather than terminating at scheme-level library calls.

The same point appears in processor and memory-system studies. Intel HEXL identifies polynomial modular multiplication and forward or inverse NTT as dominant low-level bottlenecks for BGV, BFV, and CKKS, and reports up to $7.2\times$ speedup on forward NTT, $6.7\times$ on inverse NTT, $6.0\times$ on element-wise vector-vector modular multiplication, and $1.7\times$ on vector-scalar modular multiplication through AVX512-optimized kernels (Boemer et al., 2021). HE-PIM, studying CKKS on UPMEM PIM, reaches a different but complementary conclusion: HE lowering must expose modulus-chain state, limb decomposition, basis/domain transitions, key dependencies, and communication structure because some kernels are compute-bound due to modular arithmetic while others are memory-bound due to ciphertext and metadata movement (Gupta et al., 13 May 2026). The layered design of HEIR—scheme dialects above, polynomial and RNS dialects below, with the option to exit through either library APIs or hardware dialects—is therefore consistent with the backend realities identified by these studies.

7. Ecosystem position, validation, and open questions

HEIR validates itself less through a single benchmark table than through breadth of ported techniques and integrations. The paper states that it ports a large fraction of the HE literature into one framework, including complete functionality from HECO at the tensor_ext layer, layout-selection ideas from Fhelipe, the Vos-Vos-Erkin shift-network construction, EVA’s operation balancing, several BGV and BFV noise models, Carathéodory-Fejér approximation, Paterson-Stockmeyer evaluation, Halevi-Shoup matrix-vector multiplication, and Yosys-based circuit optimization (Ali et al., 14 Aug 2025). It also cites COATL as a published system already built on HEIR and reports integrations with Belfort FPGA, Optalysys, Google TPU v6e, Niobium BASALISC, Intel HERACLES, and Cornami (Ali et al., 14 Aug 2025).

The paper further argues that HEIR is emerging as a de facto HE compiler standard. The evidence it provides is qualitative rather than metric-heavy: FHETCH identified HEIR as an excellent candidate for a standardized hardware abstraction layer; the Homomorphic Encryption Standardization organization created a compiler and accelerator working group that now focuses on HEIR; and FHE.org maintains a HEIR discussion forum (Ali et al., 14 Aug 2025). A plausible implication is that HEIR’s main historical significance lies not only in its technical layering but also in its attempt to stabilize the compiler interfaces through which future HE research can be compared.

Several limitations remain explicit. CKKS automation is incomplete because current noise models require user-provided message-range bounds and parameter selection still depends on user-provided scaling-modulus information (Ali et al., 14 Aug 2025). BGV and BFV bootstrapping are not supported because the current backends do not support them. StableHLO support is partial; C++ and ONNX frontends are prospective rather than fully implemented. Carathéodory-Fejér approximation still requires user-specified degree and interval. Some optimization stages are baseline or heuristic, such as greedy initial bootstrap placement in CKKS and limited scalar-HE bootstrap reduction beyond LUT-to-PBS conversion (Ali et al., 14 Aug 2025). The paper also does not present a formal universal semantics or a single cost model spanning all schemes, libraries, and accelerators.

Taken together, these constraints define HEIR less as a finished, closed IR than as an extensible compiler substrate. Its central contribution is architectural: it makes secrecy, scheme structure, ciphertext management, vector layout, polynomial and RNS arithmetic, library APIs, and hardware exits coexist within one compilation framework. That design turns many formerly isolated HE techniques into passes over shared representations, which is precisely the condition required for systematic comparison, recombination, and standardization in homomorphic-encryption compilation (Ali et al., 14 Aug 2025).