Documentation

• 1: Contributing to HEIR
• 2: IDE Configuration
• 3: Dialects
• 3.1: ArithExt
• 3.2: BGV
• 3.3: CGGI
• 3.4: Comb
• 3.5: Jaxite
• 3.6: LWE
• 3.7: Openfhe
• 3.8: PolyExt
• 3.9: Polynomial
• 3.10: RNS
• 3.11: Secret
• 3.12: TensorExt
• 3.13: TfheRust
• 3.14: TfheRustBool
• 4: Passes
• 4.1: ApplyFoldersPasses
• 4.2: BGVPasses
• 4.3: BGVToOpenfhe
• 4.4: BGVToPolynomial
• 4.5: CGGIPasses
• 4.6: CGGIToTfheRust
• 4.7: CGGIToTfheRustBool
• 4.8: CombToCGGI
• 4.9: ConvertIfToSelectPasses
• 4.10: ElementwiseToAffinePasses
• 4.11: ForwardStoreToLoadPasses
• 4.12: FullLoopUnrollPasses
• 4.13: LWEPasses
• 4.14: LWEToPolynomial
• 4.15: MemrefToArith
• 4.16: OpenfhePasses
• 4.17: PolynomialPasses
• 4.18: PolynomialToStandard
• 4.19: SecretizePasses
• 4.20: SecretPasses
• 4.21: SecretToBGV
• 4.22: StraightLineVectorizerPasses
• 4.23: TensorExtPasses
• 4.24: UnusedMemRefPasses
• 4.25: YosysOptimizerPasses
• 5: Design
• 5.1: Secret
• 5.2: SIMD Optimizations
• 6: Pipelines
• 7: Tutorials and Talks
• 8: Getting Started

1 - Contributing to HEIR

There are several ways to contribute to HEIR, including:

• Discussing high-level designs and questions on HEIR’s discussions page
• Improving or expanding HEIR’s documentation
• Contributing to HEIR’s code-base
• Discuss project direction at HEIR’s Working Group meetings

Ways to contribute

We welcome pull requests, and have tagged issues for newcomers:

• Good first issue
• Contributions welcome
• Research synthesis: determine what parts of recent FHE research papers can or should be ported to HEIR.

For new proposals, please open a GitHub issue or start a discussion for feedback.

Contributing to code using pull requests

Preparing a pull request

The following steps should look familiar to typical workflows for pull request contributions. Feel free to consult GitHub Help if you need more information using pull requests. HEIR-specific processes begin at the pull request review stage.

1. Sign the Contributor License Agreement (CLA). See more here.

2. Fork the HEIR repository by clicking the Fork button on the repository page. This creates a copy of the HEIR repository on your own GitHub account.

3. See Getting Started to install developer dependencies to build and run tests.

4. Add the HEIR repository as an upstream remote, so you can sync your changes against it.

   git remote add upstream https://www.github.com/google/heir
   

5. Create a development branch for your change:

    git checkout -b name-of-change
   

   And implement your changes using your favorite IDE. See IDE Configuration for more.

6. Check HEIR’s lint and style checks by running the following from the top of the repository:

    pre-commit run --all
   

7. Make sure tests are passing with the following:

    bazel test @heir//...
   

8. Once you are ready with your change, create a commit as follows.

   git add change.cpp
   git commit -m "Detailed commit message"
   git push --set-upstream origin name-of-change
   

Pull request review flow

1. New PR:

• When a new PR is submitted, it is inspected for quality requirements, such as the CLA requirement, and a sufficient PR description.
• If the PR passes checks, we assign a reviewer. If not, we request additional changes to ensure the PR passes CI checks.

2. Review

• A reviewer will check the PR and potentially request additional changes.
• If a change is needed, the contributor is requested to make a suggested change. Please make changes with additional commits to your PR, to ensure that the reviewer can easily see the diff.
• If all looks good, the reviewer will approve the PR.
• This cycle repeats itself until the PR is approved.

3. Approved

• At this stage, you must squash your commits into a single commit.
• Once the PR is approved, a GitHub workflow will check your PR for multiple commits. You may use the git rebase -i to squash the commits. Pull requests must comprise of a single git commit before merging.

4. Pull Ready

• Once the PR is squashed into a single git commit, a maintainer will apply the pull ready label.
• This initiates the internal code migration and presubmits.
• After the internal process is finished, the commit will be added to main and the PR closed as merged by that commit.

Internal review details

This diagram summarizes the GitHub/Google code synchronization process. This is largely automated by a Google-owned system called Copybara, the configuration for which is Google-internal. This system treats the Google-internal version of HEIR as the source of truth, and applies specified transformation rules to copy internal changes to GitHub and integrate external PRs internally.

Notable aspects:

• The final merged code may differ slightly from a PR. The changes are mainly to support stricter internal requirements for BUILD files that we cannot reproduce externally due to minor differences between Google’s internal build systems and bazel that we don’t know how to align. Sometimes they will also include additional code quality fixes suggested by internal static analyzers that do not exist outside of Google.
• Due to the above, signed commits with internal modifications will not maintain valid signatures after merging, which labels the commit with a warning.
• You will see various actions taken on GitHub that include copybara in the name, such as changes that originate from Google engineers doing various approved migrations (e.g., migrating HEIR to support changes in MLIR or abseil).

Why bother with Copybara?

tl;dr: Automatic syncing with upstream MLIR and associated code migration.

Until HEIR has a formal governance structure in place, Google engineers—specifically Asra Ali, Shruthi Gorantala, and Jeremy Kun—are the codebase stewards. Because the project is young and the team is small, we want to reduce our workload. One important aspect of that is keeping up to date with the upstream MLIR project and incorporating bug fixes and new features into HEIR. Google also wishes to stay up to date with MLIR and LLVM, and so it has tooling devoted to integrating new MLIR changes into Google’s monorepo every few hours. As part of that rotation, a set of approved internal projects that depend on MLIR (like TensorFlow) are patched to support breaking changes in MLIR. HEIR is one of those approved projects.

As shown in the previous section, the cost of this is that no change can go into HEIR without at least two Googlers approving it, and the project is held to a specific set of code quality standards, namely Google’s. We acknowledge these quirks, and look forward to the day when HEIR is useful enough and important enough that we can revisit this governance structure with the community.

2 - IDE Configuration

VS Code

For an out-of-tree MLIR project built with Bazel, install the following VS Code extensions:

• llvm-vs-code-extensions.vscode-mlir: Adds language support for MLIR, PDLL, and TableGen.
• llvm-vs-code-extensions.vscode-clangd: Adds clangd code completion using a generated compile_commands.json file.
• bazelbuild.vscode-bazel: Support for Bazel.

You will also need to disable ms-vscode.cpptools to avoid a conflict with clangd.

Add the following snippet to your VS Code user settings found in .vscode/settings.json to enable autocomplete based on the compile_commands.json file.

   "clangd.arguments": [
        "--compile-commands-dir=${workspaceFolder}/",
        "--completion-style=detailed",
        "--query-driver=**"
      ],

To generate the compile_commands.json file, run

bazel run @hedron_compile_commands//:refresh_all

This will need to be regenerated every time you want tooling to see new BUILD file changes.

If you encounter errors like *.h.inc not found, or syntax errors inside these files, you may need to build those targets and then re-run the refresh_all command above.

Tips for working with Bazel

Avoiding rebuilds

Bazel is notoriously fickle when it comes to deciding whether a full rebuild is necessary, which is bad for HEIR because rebuilding LLVM from scratch takes 15 minutes or more.

The main things that cause a rebuild are:

• A change to the command-line flags passed to bazel, e.g., -c opt vs -c dbg for optimization level and debug symbols.
• A change to the .bazelrc that implicitly causes a flag change. Note HEIR has its own project-specific .bazelrc in the root directory.
• A change to relevant command-line variables, such as PATH, which is avoided by the incompatible_strict_action_env flag. Note activating a python virtualenv triggers a PATH change.

Bazel compilation flags are set by default in the project root’s .bazelrc in such a way as to avoid rebuilds during development as much as possible. This includes setting -c dbg and --incompatible_strict_action_env.

Pointing HEIR to a local clone of llvm-project

Occasionally changes in HEIR will need to be made in tandem with upstream changes in MLIR. In particular, we occasionally find upstream bugs that only occur with HEIR passes, and we are the primary owners/users of the upstream polynomial dialect.

To tell bazel to use a local clone of llvm-project instead of a pinned commit hash, replace bazel/import_llvm.bzl with the following file:

cat > bazel/import_llvm.bzl << EOF
"""Provides the repository macro to import LLVM."""

def import_llvm(name):
    """Imports LLVM."""
    native.new_local_repository(
        name = name,
        # this BUILD file is intentionally empty, because the LLVM project
        # internally contains a set of bazel BUILD files overlaying the project.
        build_file_content = "# empty",
        path = "/path/to/llvm-project",
    )
EOF

The next bazel build will require a full rebuild if the checked-out LLVM commit differs from the pinned commit hash in bazel/import_llvm.bzl.

Note that you cannot reuse the LLVM CMake build artifacts in the bazel build. Based on what you’re trying to do, this may require some extra steps.

• If you just want to run existing MLIR and HEIR tests against local llvm-project changes, you can run the tests from HEIR using bazel test @llvm-project//mlir/...:all. New lit tests can be added in llvm-project’s existing directories and tested this way without a rebuild.
• If you add new CMake targets in llvm-project, then to incorporate them into HEIR you need to add new bazel targets in llvm-project/utils/bazel/llvm-project-overlay/mlir/BUILD.bazel. This is required if, for example, a new dialect or pass is added in MLIR upstream.

Send any upstream changes to HEIR-relevant MLIR files to @j2kun (Jeremy Kun) who has LLVM commit access and can also suggest additional MLIR reviewers.

3 - Dialects

This section contains the reference documentation for all of the dialects defined in HEIR.

3.1 - ArithExt

ArithExt ops

arith_ext.add (heir::arith_ext::AddOp)

Modular addition operation

Syntax:

operation ::= `arith_ext.add` operands attr-dict `:` type($output)

Computes addition modulo a statically known modulus $q$.

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

arith_ext.barrett_reduce (heir::arith_ext::BarrettReduceOp)

Compute the first step of the Barrett reduction.

Syntax:

operation ::= `arith_ext.barrett_reduce` operands attr-dict `:` qualified(type($input))

Let $q$ denote a statically known modulus and $b = 4^{w}$, where $w$ is the smallest bit-width that contains the range $[0, q)$. The Barrett reduce operation computes barret_reduce x = x - floor(x * floor(b / q) / b) * q.

Given $0 <= x < q^2$, then this will compute $(x \mod q)$ or $(x \mod q) + p$.

Traits: SameOperandsAndResultType

Interfaces: InferTypeOpInterface

Attributes:

Operands:

Results:

arith_ext.mac (heir::arith_ext::MacOp)

Modular multiplication-and-accumulation operation

Syntax:

operation ::= `arith_ext.mac` operands attr-dict `:` type($output)

arith_ext.mac x, y, z {modulus = q} computes $(x * y) + z \mod q$

Traits: AlwaysSpeculatableImplTrait, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

arith_ext.mul (heir::arith_ext::MulOp)

Modular multiplication operation

Syntax:

operation ::= `arith_ext.mul` operands attr-dict `:` type($output)

Computes multiplication modulo a statically known modulus $q$.

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

arith_ext.subifge (heir::arith_ext::SubIfGEOp)

Compute (x >= y) ? x - y : x.

Syntax:

operation ::= `arith_ext.subifge` operands attr-dict `:` qualified(type($output))

Traits: SameOperandsAndResultType

Interfaces: InferTypeOpInterface

Operands:

Results:

arith_ext.sub (heir::arith_ext::SubOp)

Modular subtraction operation

Syntax:

operation ::= `arith_ext.sub` operands attr-dict `:` type($output)

Computes subtraction modulo a statically known modulus $q$.

Traits: AlwaysSpeculatableImplTrait, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

3.2 - BGV

The BGV dialect defines the types and operations of the BGV cryptosystem.

BGV ops

bgv.add (heir::bgv::AddOp)

Addition operation between ciphertexts.

Syntax:

operation ::= `bgv.add` operands attr-dict `:` qualified(type($output))

Traits: Commutative, SameOperandsAndResultType

Interfaces: InferTypeOpInterface

Operands:

Results:

bgv.add_plain (heir::bgv::AddPlainOp)

Addition operation between ciphertext-plaintext.

Syntax:

operation ::= `bgv.add_plain` operands attr-dict `:`  functional-type(operands, results)

Interfaces: InferTypeOpInterface

Operands:

Results:

bgv.extract (heir::bgv::ExtractOp)

Extract the i-th element of a ciphertext.

Syntax:

operation ::= `bgv.extract` operands attr-dict `:`  functional-type(operands, results)

While this operation is costly to compute in FHE, we represent it so we can implement efficient lowerings and folders.

This op can be implemented as a plaintext multiplication with a one-hot vector and a rotate into the zero-th index.

An extraction op’s input ciphertext type is asserted to have an underlying_type corresponding to a ranked tensor type, and this op’s return type is inferred to have the underlying_type corresponding to the element type of that tensor type.

Traits: SameOperandsAndResultRings

Operands:

Results:

bgv.modulus_switch (heir::bgv::ModulusSwitchOp)

Lower the modulus level of the ciphertext.

Syntax:

operation ::= `bgv.modulus_switch` operands attr-dict `:` qualified(type($input)) `->` qualified(type($output))

Attributes:

Operands:

Results:

bgv.mul (heir::bgv::MulOp)

Multiplication operation between ciphertexts.

Syntax:

operation ::= `bgv.mul` operands attr-dict `:`  functional-type(operands, results)

Traits: Commutative, InferTypeOpAdaptor, SameOperandsAndResultRings, SameTypeOperands

Interfaces: InferTypeOpInterface

Operands:

Results:

bgv.mul_plain (heir::bgv::MulPlainOp)

Multiplication operation between ciphertext-plaintext.

Syntax:

operation ::= `bgv.mul_plain` operands attr-dict `:`  functional-type(operands, results)

Interfaces: InferTypeOpInterface

Operands:

Results:

bgv.negate (heir::bgv::NegateOp)

Negate the coefficients of the ciphertext.

Syntax:

operation ::= `bgv.negate` operands attr-dict `:` qualified(type($output))

Traits: SameOperandsAndResultType

Interfaces: InferTypeOpInterface

Operands:

Results:

bgv.relinearize (heir::bgv::RelinearizeOp)

Relinearize the ciphertext.

Syntax:

operation ::= `bgv.relinearize` operands attr-dict `:` qualified(type($input)) `->` qualified(type($output))

This op takes integer array attributes from_basis and to_basis that are used to indicate the key basis from which and to which the ciphertext is encrypted against. A ciphertext is canonically encrypted against key basis (1, s). After a multiplication, its size will increase and the basis will be (1, s, s^2). The array that represents the key basis is constructed by listing the powers of s at each position of the array. For example, (1, s, s^2) corresponds to [0, 1, 2], while (1, s^2) corresponds to [0, 2].

Traits: InferTypeOpAdaptor, SameOperandsAndResultRings

Interfaces: InferTypeOpInterface

Attributes:

Operands:

Results:

bgv.rotate (heir::bgv::RotateOp)

Rotate the coefficients of the ciphertext using a Galois automorphism.

Syntax:

operation ::= `bgv.rotate` operands attr-dict `:` qualified(type($input))

Interfaces: InferTypeOpInterface

Attributes:

Operands:

Results:

bgv.sub (heir::bgv::SubOp)

Subtraction operation between ciphertexts.

Syntax:

operation ::= `bgv.sub` operands attr-dict `:` qualified(type($output))

Traits: SameOperandsAndResultType

Interfaces: InferTypeOpInterface

Operands:

Results:

bgv.sub_plain (heir::bgv::SubPlainOp)

Subtraction operation between ciphertext-plaintext.

Syntax:

operation ::= `bgv.sub_plain` operands attr-dict `:`  functional-type(operands, results)

Interfaces: InferTypeOpInterface

Operands:

Results:

3.3 - CGGI

A dialect for types and operations in the CGGI cryptosystem

CGGI attributes

CGGIParamsAttr

Syntax:

#cggi.cggi_params<
  ::mlir::heir::lwe::RLWEParamsAttr,   # rlweParams
  unsigned,   # bsk_noise_variance
  unsigned,   # bsk_gadget_base_log
  unsigned,   # bsk_gadget_num_levels
  unsigned,   # ksk_noise_variance
  unsigned,   # ksk_gadget_base_log
  unsigned   # ksk_gadget_num_levels
>

Parameters:

CGGI ops

cggi.and (heir::cggi::AndOp)

Logical AND of two ciphertexts.

Syntax:

operation ::= `cggi.and` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

cggi.lut2 (heir::cggi::Lut2Op)

A lookup table on two inputs.

Syntax:

operation ::= `cggi.lut2` operands attr-dict `:` qualified(type($output))

An op representing a lookup table applied to some number n of ciphertexts encrypting boolean input bits.

Over cleartext bits a, b, c, using n = 3 for example, the operation computed by this function can be interpreted as

  truth_table >> {c, b, a}

where {c, b, a} is the unsigned 3-bit integer with bits c, b, a from most significant bit to least-significant bit. The input are combined into a single ciphertext input to the lookup table using products with plaintexts and sums.

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, LUTOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

cggi.lut3 (heir::cggi::Lut3Op)

A lookup table on three inputs.

Syntax:

operation ::= `cggi.lut3` operands attr-dict `:` qualified(type($output))

An op representing a lookup table applied to some number n of ciphertexts encrypting boolean input bits.

Over cleartext bits a, b, c, using n = 3 for example, the operation computed by this function can be interpreted as

  truth_table >> {c, b, a}

where {c, b, a} is the unsigned 3-bit integer with bits c, b, a from most significant bit to least-significant bit. The input are combined into a single ciphertext input to the lookup table using products with plaintexts and sums.

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, LUTOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

cggi.lut_lincomb (heir::cggi::LutLinCombOp)

A variadic-input lookup table with inputs prepared via linear combination.

Syntax:

operation ::= `cggi.lut_lincomb` operands attr-dict `:` type($output)

An op representing a lookup table applied to an arbitrary number of input ciphertexts, which are combined according to a static linear combination attached to the op.

The user must ensure the chosen linear combination does not bleed error bits into the message space according to the underlying ciphertext’s encoding attributes. E.g., a bit_field_encoding with 3 cleartext bits cannot be multiplied by 16.

Example:

#encoding = #lwe.bit_field_encoding<cleartext_start=30, cleartext_bitwidth=3>
#params = #lwe.lwe_params<cmod=7917, dimension=4>
!ciphertext = !lwe.lwe_ciphertext<encoding = #encoding, lwe_params = #params>

%4 = cggi.lut_lincomb %c0, %c1, %c2, %c3 {coefficients = array<i32: 1, 2, 3, 2>, lookup_table = 68 : index} : !ciphertext

Represents applying the lut

  68 >> (1 * c0 + 2 * c1 + 3 * c2 + 2 * c3)

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, LUTOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

cggi.multi_lut_lincomb (heir::cggi::MultiLutLinCombOp)

A multi-output version of lut_lincomb with one LUT per output.

Syntax:

operation ::= `cggi.multi_lut_lincomb` operands attr-dict `:` functional-type($inputs, $outputs)

An op representing multiple lookup tables applied to a shared input, which is prepared via a static linear combination. This is equivalent to cggi.lut_lincomb, but where the linear combination is given to multiple lookup tables, each producing a separate output.

This can be achieved by a special implementation of blind rotate in the CGGI scheme. See AutoHoG.

Example:

#encoding = #lwe.bit_field_encoding<cleartext_start=30, cleartext_bitwidth=3>
#params = #lwe.lwe_params<cmod=7917, dimension=4>
!ciphertext = !lwe.lwe_ciphertext<encoding = #encoding, lwe_params = #params>

%4 = cggi.multi_lut_lincomb %c0, %c1, %c2, %c3 {
    coefficients = array<i32: 1, 2, 3, 2>,
    lookup_tables = array<index: 68, 70, 4, 8>
} : (!ciphertext, !ciphertext, !ciphertext, !ciphertext) -> (!ciphertext, !ciphertext, !ciphertext, !ciphertext)

Represents applying the following LUTs. Performance-wise, this is comparable to applying a single LUT to a linear combination.

x = (1 * c0 + 2 * c1 + 3 * c2 + 2 * c3)
return (
  (68 >> x) & 1,
  (70 >> x) & 1,
  (4 >> x) & 1,
  (8 >> x) & 1
)

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

cggi.nand (heir::cggi::NandOp)

Logical NAND of two ciphertexts.

Syntax:

operation ::= `cggi.nand` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

cggi.nor (heir::cggi::NorOp)

Logical NOR of two ciphertexts.

Syntax:

operation ::= `cggi.nor` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

cggi.not (heir::cggi::NotOp)

Logical NOT of two ciphertexts

Syntax:

operation ::= `cggi.not` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Elementwise, Involution, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

cggi.or (heir::cggi::OrOp)

Logical OR of two ciphertexts.

Syntax:

operation ::= `cggi.or` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

cggi.xnor (heir::cggi::XNorOp)

Logical XNOR of two ciphertexts.

Syntax:

operation ::= `cggi.xnor` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

cggi.xor (heir::cggi::XorOp)

Logical XOR of two ciphertexts.

Syntax:

operation ::= `cggi.xor` operands attr-dict `:` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait, Commutative, Elementwise, SameOperandsAndResultType, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

3.4 - Comb

Types and operations for comb dialect This dialect defines the comb dialect, which is intended to be a generic representation of combinational logic outside of a particular use-case.

Operations

comb.add (heir::comb::AddOp)

Syntax:

operation ::= `comb.add` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.and (heir::comb::AndOp)

Syntax:

operation ::= `comb.and` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.concat (heir::comb::ConcatOp)

Concatenate a variadic list of operands together.

Syntax:

operation ::= `comb.concat` $inputs attr-dict `:` qualified(type($inputs))

See the comb rationale document for details on operand ordering.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

comb.extract (heir::comb::ExtractOp)

Extract a range of bits into a smaller value, lowBit specifies the lowest bit included.

Syntax:

operation ::= `comb.extract` $input `from` $lowBit attr-dict `:` functional-type($input, $result)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.icmp (heir::comb::ICmpOp)

Compare two integer values

Syntax:

operation ::= `comb.icmp` (`bin` $twoState^)? $predicate $lhs `,` $rhs attr-dict `:` qualified(type($lhs))

This operation compares two integers using a predicate. If the predicate is true, returns 1, otherwise returns 0. This operation always returns a one bit wide result.

    %r = comb.icmp eq %a, %b : i4

Traits: AlwaysSpeculatableImplTrait, SameTypeOperands

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.inv (heir::comb::InvOp)

Syntax:

operation ::= `comb.inv` (`bin` $twoState^)? $input attr-dict `:` qualified(type($input))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.mul (heir::comb::MulOp)

Syntax:

operation ::= `comb.mul` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.mux (heir::comb::MuxOp)

Return one or the other operand depending on a selector bit

Syntax:

operation ::= `comb.mux` (`bin` $twoState^)? $cond `,` $trueValue `,` $falseValue  attr-dict `:` qualified(type($result))

  %0 = mux %pred, %tvalue, %fvalue : i4

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.nand (heir::comb::NandOp)

Syntax:

operation ::= `comb.nand` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.nor (heir::comb::NorOp)

Syntax:

operation ::= `comb.nor` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.or (heir::comb::OrOp)

Syntax:

operation ::= `comb.or` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.parity (heir::comb::ParityOp)

Syntax:

operation ::= `comb.parity` (`bin` $twoState^)? $input attr-dict `:` qualified(type($input))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.replicate (heir::comb::ReplicateOp)

Concatenate the operand a constant number of times

Syntax:

operation ::= `comb.replicate` $input attr-dict `:` functional-type($input, $result)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

comb.truth_table (heir::comb::TruthTableOp)

Return a true/false based on a lookup table

Syntax:

operation ::= `comb.truth_table` $inputs `->` $lookupTable attr-dict

  %a = ... : i1
  %b = ... : i1
  %0 = comb.truth_table %a, %b -> 6 : ui4

This operation assumes that the lookup table is described as an integer of 2^n bits to fully specify the table. Inputs are sorted MSB -> LSB from left to right and the offset into lookupTable is computed from them. The integer containing the truth table value’s LSB is the output for the input “all false”, and the MSB is the output for the input “all true”.

No difference from array_get into an array of constants except for xprop behavior. If one of the inputs is unknown, but said input doesn’t make a difference in the output (based on the lookup table) the result should not be ‘x’ – it should be the well-known result.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, LUTOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.xnor (heir::comb::XNorOp)

Syntax:

operation ::= `comb.xnor` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.xor (heir::comb::XorOp)

Syntax:

operation ::= `comb.xor` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

Enums

ICmpPredicate

hw.icmp comparison predicate

Cases:

Comb types

Comb ops

comb.add (heir::comb::AddOp)

Syntax:

operation ::= `comb.add` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.and (heir::comb::AndOp)

Syntax:

operation ::= `comb.and` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.concat (heir::comb::ConcatOp)

Concatenate a variadic list of operands together.

Syntax:

operation ::= `comb.concat` $inputs attr-dict `:` qualified(type($inputs))

See the comb rationale document for details on operand ordering.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

comb.extract (heir::comb::ExtractOp)

Extract a range of bits into a smaller value, lowBit specifies the lowest bit included.

Syntax:

operation ::= `comb.extract` $input `from` $lowBit attr-dict `:` functional-type($input, $result)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.icmp (heir::comb::ICmpOp)

Compare two integer values

Syntax:

operation ::= `comb.icmp` (`bin` $twoState^)? $predicate $lhs `,` $rhs attr-dict `:` qualified(type($lhs))

This operation compares two integers using a predicate. If the predicate is true, returns 1, otherwise returns 0. This operation always returns a one bit wide result.

    %r = comb.icmp eq %a, %b : i4

Traits: AlwaysSpeculatableImplTrait, SameTypeOperands

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.inv (heir::comb::InvOp)

Syntax:

operation ::= `comb.inv` (`bin` $twoState^)? $input attr-dict `:` qualified(type($input))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.mul (heir::comb::MulOp)

Syntax:

operation ::= `comb.mul` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.mux (heir::comb::MuxOp)

Return one or the other operand depending on a selector bit

Syntax:

operation ::= `comb.mux` (`bin` $twoState^)? $cond `,` $trueValue `,` $falseValue  attr-dict `:` qualified(type($result))

  %0 = mux %pred, %tvalue, %fvalue : i4

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.nand (heir::comb::NandOp)

Syntax:

operation ::= `comb.nand` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.nor (heir::comb::NorOp)

Syntax:

operation ::= `comb.nor` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.or (heir::comb::OrOp)

Syntax:

operation ::= `comb.or` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.parity (heir::comb::ParityOp)

Syntax:

operation ::= `comb.parity` (`bin` $twoState^)? $input attr-dict `:` qualified(type($input))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.replicate (heir::comb::ReplicateOp)

Concatenate the operand a constant number of times

Syntax:

operation ::= `comb.replicate` $input attr-dict `:` functional-type($input, $result)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

comb.truth_table (heir::comb::TruthTableOp)

Return a true/false based on a lookup table

Syntax:

operation ::= `comb.truth_table` $inputs `->` $lookupTable attr-dict

  %a = ... : i1
  %b = ... : i1
  %0 = comb.truth_table %a, %b -> 6 : ui4

This operation assumes that the lookup table is described as an integer of 2^n bits to fully specify the table. Inputs are sorted MSB -> LSB from left to right and the offset into lookupTable is computed from them. The integer containing the truth table value’s LSB is the output for the input “all false”, and the MSB is the output for the input “all true”.

No difference from array_get into an array of constants except for xprop behavior. If one of the inputs is unknown, but said input doesn’t make a difference in the output (based on the lookup table) the result should not be ‘x’ – it should be the well-known result.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, LUTOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.xnor (heir::comb::XNorOp)

Syntax:

operation ::= `comb.xnor` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

comb.xor (heir::comb::XorOp)

Syntax:

operation ::= `comb.xor` (`bin` $twoState^)? $inputs attr-dict `:` qualified(type($result))

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType, SameTypeOperands

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

3.5 - Jaxite

The jaxite dialect is an exit dialect for generating py code against the jaxite library API, using the jaxite parameters and encoding scheme.

See https://github.com/google/jaxite

Jaxite types

ParamsType

The jaxite security params required to perform homomorphic operations.

Syntax: !jaxite.params

ServerKeySetType

The jaxite server key set required to perform homomorphic operations.

Syntax: !jaxite.server_key_set

Jaxite ops

jaxite.constant (heir::jaxite::ConstantOp)

Syntax:

operation ::= `jaxite.constant` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

jaxite.lut3 (heir::jaxite::Lut3Op)

Syntax:

operation ::= `jaxite.lut3` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

3.6 - LWE

LWE attributes

BitFieldEncodingAttr

An attribute describing encoded LWE plaintexts using bit fields.

Syntax:

#lwe.bit_field_encoding<
  unsigned,   # cleartext_start
  unsigned   # cleartext_bitwidth
>

A bit field encoding of an integer describes which contiguous region of bits a small integer occupies within a larger integer.

The data describing the encoding consists of the starting bit positions of the cleartext bit field and its width, where the LSB is bit 0 and the MSB is bit bit_width-1. So the above example would have starting bit 30 and width 3. The bits not specified for the message have semantics defined by the scheme or lowering.

Note that this encoding does not specify the underlying bit width of the plaintext space. This is left for lowerings to decide.

The presence of this attribute as the encoding attribute of a tensor indicates that the tensor is an LWE ciphertext.

Example (CGGI):

#encoding = #lwe.bit_field_encoding<cleartext_start=30, cleartext_bitwidth=3>
!plaintext = !lwe.lwe_plaintext<encoding = #encoding>

%0 = arith.constant 4 : i3
%1 = lwe.encode %0 { encoding = #encoding }: i3 to !plaintext

The above represents an LWE plaintext encoding the 3-bit cleartext 4 as an LWE ciphertext in a 32-bit integer, with a single bit of padding at the MSB. This corresponds to the following, where 0 denotes a 0 bit, b denotes a bit of the cleartext, n denotes a bit reserved for noise, and | is a visual aid to show where the bit fields begin and end.

   0|bbb|nn...n
MSB^          ^LSB

Example (BGV):

Note: BGV uses the RLWE encodings, but they have the same bit-field encoding attributes as here. So this example serves mainly to show how this attribute can be used to specify storing bits in the LSB of a plaintext.

#encoding = #lwe.bit_field_encoding<cleartext_start=4, cleartext_bitwidth=4>
!plaintext = !lwe.lwe_plaintext<encoding = #encoding>

%0 = arith.constant 9 : i4
%1 = lwe.encode %0 { encoding = #encoding }: i4 to !plaintext

The above represents an LWE plaintext encoding a 4-bit cleartext as an LWE ciphertext in the least-significant bits of a larger integer. This corresponds to the following.

   nn...n|bbbb
MSB^         ^LSB

Parameters:

LWEParamsAttr

Syntax:

#lwe.lwe_params<
  IntegerAttr,   # cmod
  unsigned   # dimension
>

Parameters:

RLWEParamsAttr

Syntax:

#lwe.rlwe_params<
  unsigned,   # dimension
  ::mlir::polynomial::RingAttr   # ring
>

An attribute describing classical RLWE parameters:

• dimension: the number of polynomials used in an RLWE sample, analogous to LWEParams.dimension.
• ring: the polynomial ring to use.

Parameters:

UnspecifiedBitFieldEncodingAttr

An attribute describing unspecified bit field encodings.

Syntax:

#lwe.unspecified_bit_field_encoding<
  unsigned   # cleartext_bitwidth
>

See LWE_BitFieldEncoding for a description of bit field encodings.

This attribute describes an unspecified bit field encoding; this is where the starting bit position of the cleartext bit field is unspecified, but its width is fixed. A noise growth analysis should be performed to determine the optimal amount of bits needed for noise and padding to specify the bit field encodings starting bit position.

Example:

#lwe_encoding = #lwe.unspecified_bit_field_encoding<cleartext_bitwidth=3>
%lwe_ciphertext = arith.constant <[1,2,3,4]> : tensor<4xi32, #lwe_encoding>

Parameters:

InverseCanonicalEmbeddingEncodingAttr

An attribute describing encoded RLWE plaintexts via the rounded inverse canonical embedding.

Syntax:

#lwe.inverse_canonical_embedding_encoding<
  unsigned,   # cleartext_start
  unsigned   # cleartext_bitwidth
>

Let $n$ be the degree of the polynomials in the plaintext space. An “inverse canonical embedding encoding” of a list of real or complex values $v_1, \dots, v_{n/2}$ is (almost) the inverse of the following decoding map.

Define a map $\tau_N$ that maps a polynomial $p \in \mathbb{Z}[x] / (x^N + 1) \to \mathbb{C}^{N/2}$ by evaluating it at the following $N/2$ points, where $\omega = e^{2 \pi i / 2N}$ is the primitive $2N$th root of unity:

[ \omega, \omega^3, \omega^5, \dots, \omega^{N-1} ]

Then the complete decoding operation is $\textup{Decode}(p) = (1/\Delta)\tau_N(p)$, where $\Delta$ is a scaling parameter and $\tau_N$ is the truncated canonical embedding above. The encoding operation is the inverse of the decoding operation, with some caveats explained below.

The map $\tau_N$ is derived from the so-called canonical embedding $\tau$, though in the standard canonical embedding, we evaluate at all odd powers of the root of unity, $\omega, \omega^3, \dots, \omega^{2N-1}$. For polynomials in the slightly larger space $\mathbb{R}[x] / (x^N + 1)$, the image of the canonical embedding is the subspace $H \subset \mathbb{C}^N$ defined by tuples $(z_1, \dots, z_N)$ such that $\overline{z_i} = \overline{z_{N-i+1}}$. Note that this property holds because polynomial evaluation commutes with complex conjugates, and the second half of the roots of unity evaluate are complex conjugates of the first half. The converse, that any such tuple with complex conjugate symmetry has an inverse under $\tau$ with all real coefficients, makes $\tau$ is a bijection onto $H$. $\tau$ and its inverse are explicitly computable as discrete Fourier Transforms.

Because of the symmetry in canonical embedding for real polynomials, inputs to this encoding can be represented as a list of $N/2$ complex points, with the extra symmetric structure left implicit. $\tau_N$ and its inverse can also be explicitly computed without need to expand the vectors to length $N$.

The rounding step is required to invert the decoding because, while cleartexts must be (implicitly) in the subspace $H$, they need not be the output of $\tau_N$ for an integer polynomial. The rounding step ensures we can use integer polynomial plaintexts for the FHE operations. There are multiple rounding mechanisms, and this attribute does not specify which is used, because in theory two ciphertexts that have used different roundings are still compatible, though they may have different noise growth patterns.

The scaling parameter $\Delta$ is specified by the cleartext_start and cleartext_bitwidth parameters, which are applied coefficient-wise using the same semantics as the bit_field_encoding.

This attribute can be used in multiple ways:

• On a poly.poly, it asserts that the polynomial has been transformed from a coefficient list using the canonical embedding.
• On a tensor of poly.poly, it asserts that the tensor is an RLWE ciphertext for some RLWE scheme that supports the approximate embedding encoding.

A typical flow for the CKKS scheme using this encoding would be to apply an inverse FFT operation to invert the canonical embedding to be a polynomial with real coefficients, then encrypt scale the resulting polynomial’s coefficients according to the scaling parameters, then round to get integer coefficients.

Example:

#generator = #poly.polynomial<1 + x**1024>
#ring = #poly.ring<cmod=65536, ideal=#generator>
#lwe_encoding = #lwe.polynomial_evaluation_encoding<cleartext_start=30, cleartext_bitwidth=3>

%evals = arith.constant <[1, 2, 4, 5]> : tensor<4xi16>
%poly1 = poly.intt %evals : tensor<4xi16, #ring> -> !poly.poly<#ring, #eval_encoding>
%poly2 = poly.intt %evals : tensor<4xi16, #ring> -> !poly.poly<#ring, #eval_encoding>
%rlwe_ciphertext = tensor.from_elements %poly1, %poly2 : tensor<2x!poly.poly<#ring, #eval_encoding>>

See bit_field_encoding for the definition of the cleartext_start and cleartext_bitwidth fields.

Parameters:

PolynomialCoefficientEncodingAttr

An attribute describing encoded RLWE plaintexts via coefficients.

Syntax:

#lwe.polynomial_coefficient_encoding<
  unsigned,   # cleartext_start
  unsigned   # cleartext_bitwidth
>

A coefficient encoding of a list of integers asserts that the coefficients of the polynomials contain the cleartexts, with the same semantics as bit_field_encoding for per-coefficient encodings.

The presence of this attribute as the encoding attribute of a tensor of poly.poly indicates that the tensor is an RLWE ciphertext for some RLWE scheme that supports the coefficient encoding.

See bit_field_encoding for the definition of the cleartext_start and cleartext_bitwidth fields.

Example:

#generator = #poly.polynomial<1 + x**1024>
#ring = #poly.ring<cmod=65536, ideal=#generator>
#coeff_encoding = #lwe.polynomial_coefficient_encoding<cleartext_start=15, cleartext_bitwidth=4>

%poly1 = poly.from_tensor %coeffs1 : tensor<10xi16> -> !poly.poly<#ring>
%poly2 = poly.from_tensor %coeffs2 : tensor<10xi16> -> !poly.poly<#ring>
%rlwe_ciphertext = tensor.from_elements %poly1, %poly2 : tensor<2x!poly.poly<#ring>, #coeff_encoding>

Parameters:

PolynomialEvaluationEncodingAttr

An attribute describing encoded RLWE plaintexts via evaluations at fixed points.

Syntax:

#lwe.polynomial_evaluation_encoding<
  unsigned,   # cleartext_start
  unsigned   # cleartext_bitwidth
>

A “evaluation encoding” of a list of integers $(v_1, \dots, v_n)$ asserts that $f(x_1 ) = v_1, \dots, f(x_n) = v_n$ for some implicit, but fixed and distinct choice of inputs $x_i$. The encoded values are also scaled by a scale factor, having the same semantics as bit_field_encoding, but applied entry-wise (to either the coefficient or evaluation representation).

This attribute can be used in multiple ways:

• On a poly.poly, it asserts that the polynomial has been transformed from an evaluation tensor.
• On a tensor of poly.poly, it asserts that the tensor is an RLWE ciphertext for some RLWE scheme that supports the evaluation encoding.

A typical workflow for the BFV/BGV schemes using this encoding would be to apply a INTT operation to the input list of cleartexts to convert from evaluation form to coefficient form, then encrypt the resulting polynomial in coefficient form, then apply NTT back to the evaluation form for faster multiplication of ciphertexts.

The points chosen are fixed to be the powers of a primitive root of unity of the coefficient ring of the plaintext space, which allows one to use NTT/INTT to tansform quickly between the coefficient and evaluation forms.

Example:

#generator = #poly.polynomial<1 + x**1024>
// note that the cmod should be chosen so as to ensure a primitive root of
// unity exists in the multiplicative group (Z / cmod Z)^*
#ring = #poly.ring<cmod=65536, ideal=#generator>
#lwe_encoding = #lwe.polynomial_evaluation_encoding<cleartext_start=30, cleartext_bitwidth=3>

%evals = arith.constant <[1, 2, 4, 5]> : tensor<4xi16>
%poly1 = poly.intt %evals : tensor<4xi16, #ring> -> !poly.poly<#ring, #eval_encoding>
%poly2 = poly.intt %evals : tensor<4xi16, #ring> -> !poly.poly<#ring, #eval_encoding>
%rlwe_ciphertext = tensor.from_elements %poly1, %poly2 : tensor<2x!poly.poly<#ring, #eval_encoding>>

See bit_field_encoding for the definition of the cleartext_start and cleartext_bitwidth fields.

Parameters:

LWE types

LWECiphertextType

A type for LWE ciphertexts

Syntax:

!lwe.lwe_ciphertext<
  ::mlir::Attribute,   # encoding
  LWEParamsAttr   # lwe_params
>

A type for LWE ciphertexts.

This type keeps track of the plaintext integer encoding for the LWE Ciphertext to ensure proper decoding after decryption. It also keeps track of the ring where the LWE ciphertext is defined, which provides information on the ciphertext shape and the ring operations used in LWE operations.

Parameters:

LWEPlaintextType

A type for LWE plaintexts

Syntax:

!lwe.lwe_plaintext<
  ::mlir::Attribute   # encoding
>

A type for LWE plaintexts.

This type keeps track of the plaintext integer encoding for the LWE plaintext before it is encrypted.

Parameters:

RLWECiphertextType

A type for RLWE ciphertexts

Syntax:

!lwe.rlwe_ciphertext<
  ::mlir::Attribute,   # encoding
  RLWEParamsAttr,   # rlwe_params
  Type   # underlying_type
>

Parameters:

RLWEPlaintextType

A type for RLWE plaintexts

Syntax:

!lwe.rlwe_plaintext<
  ::mlir::Attribute,   # encoding
  ::mlir::polynomial::RingAttr,   # ring
  Type   # underlying_type
>

Parameters:

RLWEPublicKeyType

A public key for RLWE

Syntax:

!lwe.rlwe_public_key<
  RLWEParamsAttr   # rlwe_params
>

Parameters:

RLWESecretKeyType

A secret key for RLWE

Syntax:

!lwe.rlwe_secret_key<
  RLWEParamsAttr   # rlwe_params
>

Parameters:

LWE ops

lwe.add (heir::lwe::AddOp)

Add two LWE ciphertexts

Syntax:

operation ::= `lwe.add` operands attr-dict `:` type($output)

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

lwe.encode (heir::lwe::EncodeOp)

Encode an integer to yield an LWE plaintext

Syntax:

operation ::= `lwe.encode` $plaintext attr-dict `:` qualified(type($plaintext)) `to` qualified(type($output))

Encode an integer to yield an LWE plaintext.

This op uses a an encoding attribute to encode the bits of the integer into an LWE plaintext value that can then be encrypted.

Examples:

%Y = lwe.encode %value {encoding = #enc}: i1 to !lwe.lwe_plaintext<encoding = #enc>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

lwe.mul_scalar (heir::lwe::MulScalarOp)

Multiply an LWE ciphertext by a scalar

Syntax:

operation ::= `lwe.mul_scalar` operands attr-dict `:`  functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, Commutative

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

lwe.rlwe_decode (heir::lwe::RLWEDecodeOp)

Decode an RLWE plaintext to an underlying type

Syntax:

operation ::= `lwe.rlwe_decode` $input attr-dict `:` qualified(type($input)) `->` qualified(type($output))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

lwe.rlwe_decrypt (heir::lwe::RLWEDecryptOp)

Decrypt an RLWE ciphertext to a RLWE plaintext

Syntax:

operation ::= `lwe.rlwe_decrypt` operands attr-dict `:`  functional-type(operands, results)

Decrypt an RLWE ciphertext to yield a RLWE plaintext

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

lwe.rlwe_encode (heir::lwe::RLWEEncodeOp)

Encode an integer to yield an RLWE plaintext

Syntax:

operation ::= `lwe.rlwe_encode` $input attr-dict `:` qualified(type($input)) `->` qualified(type($output))

Encode an integer to yield an RLWE plaintext.

This op uses a an encoding attribute to encode the bits of the integer into an RLWE plaintext value that can then be encrypted.

Examples:

%Y = lwe.rlwe_encode %value {encoding = #enc, ring = #ring}: i1 to !lwe.rlwe_plaintext<encoding = #enc, ring = #ring>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

lwe.rlwe_encrypt (heir::lwe::RLWEEncryptOp)

Encrypt an RLWE plaintext to a RLWE ciphertext

Syntax:

operation ::= `lwe.rlwe_encrypt` operands attr-dict `:`  functional-type(operands, results)

Encrypt an RLWE plaintext to yield a RLWE ciphertext.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

lwe.trivial_encrypt (heir::lwe::TrivialEncryptOp)

Create a trivial encryption of a plaintext.

Syntax:

operation ::= `lwe.trivial_encrypt` operands attr-dict `:`  qualified(type(operands)) `to` qualified(type(results))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

lwe.reinterpret_underlying_type (heir::lwe::ReinterpretUnderlyingTypeOp)

A placeholder cast from one ciphertext type to another

Syntax:

operation ::= `lwe.reinterpret_underlying_type` $input attr-dict `:` qualified(type($input)) `to` qualified(type($output))

The cast op is thus used to translate underlying_type between ciphertexts in particular situations , such as when lowering to an API that does not keep track of types for you.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

3.7 - Openfhe

The openfhe dialect is an exit dialect for generating c++ code against the OpenFHE library API.

See https://github.com/openfheorg/openfhe-development

Openfhe types

CCParamsType

The CCParams required to create CryptoContext.

Syntax: !openfhe.cc_params

CryptoContextType

The CryptoContext required to perform homomorphic operations in OpenFHE.

Syntax: !openfhe.crypto_context

EvalKeyType

The evaluation key required to keyswitch/relinearize/rotate/automorphism operation in OpenFHE.

Syntax: !openfhe.eval_key

PrivateKeyType

The private key required to decrypt a ciphertext in OpenFHE.

Syntax: !openfhe.private_key

PublicKeyType

The public key required to encrypt plaintext in OpenFHE.

Syntax: !openfhe.public_key

Openfhe ops

openfhe.add (heir::openfhe::AddOp)

OpenFHE add operation of two ciphertexts.

Syntax:

operation ::= `openfhe.add` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.automorph (heir::openfhe::AutomorphOp)

Syntax:

operation ::= `openfhe.automorph` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.decrypt (heir::openfhe::DecryptOp)

Syntax:

operation ::= `openfhe.decrypt` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.encrypt (heir::openfhe::EncryptOp)

Syntax:

operation ::= `openfhe.encrypt` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.gen_context (heir::openfhe::GenContextOp)

Syntax:

operation ::= `openfhe.gen_context` operands attr-dict `:` functional-type(operands, results)

Interfaces: InferTypeOpInterface

Operands:

Results:

openfhe.gen_mulkey (heir::openfhe::GenMulKeyOp)

Syntax:

operation ::= `openfhe.gen_mulkey` operands attr-dict `:` functional-type(operands, results)

Operands:

openfhe.gen_params (heir::openfhe::GenParamsOp)

Syntax:

operation ::= `openfhe.gen_params` operands attr-dict `:` functional-type(operands, results)

Interfaces: InferTypeOpInterface

Attributes:

Results:

openfhe.gen_rotkey (heir::openfhe::GenRotKeyOp)

Syntax:

operation ::= `openfhe.gen_rotkey` operands attr-dict `:` functional-type(operands, results)

Attributes:

Operands:

openfhe.key_switch (heir::openfhe::KeySwitchOp)

Syntax:

operation ::= `openfhe.key_switch` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.level_reduce (heir::openfhe::LevelReduceOp)

OpenFHE level_reduce operation of a ciphertext.

Syntax:

operation ::= `openfhe.level_reduce` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.mod_reduce (heir::openfhe::ModReduceOp)

OpenFHE mod_reduce operation of a ciphertext. (used only for BGV/CKKS)

Syntax:

operation ::= `openfhe.mod_reduce` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.mul_const (heir::openfhe::MulConstOp)

OpenFHE mul operation of a ciphertext and a constant.

Syntax:

operation ::= `openfhe.mul_const` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.mul_no_relin (heir::openfhe::MulNoRelinOp)

OpenFHE mul operation of two ciphertexts without relinearization.

Syntax:

operation ::= `openfhe.mul_no_relin` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.mul (heir::openfhe::MulOp)

OpenFHE mul operation of two ciphertexts with relinearization.

Syntax:

operation ::= `openfhe.mul` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.mul_plain (heir::openfhe::MulPlainOp)

OpenFHE mul operation of a ciphertext and a plaintext.

Syntax:

operation ::= `openfhe.mul_plain` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.negate (heir::openfhe::NegateOp)

OpenFHE negate operation of a ciphertext.

Syntax:

operation ::= `openfhe.negate` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.relin (heir::openfhe::RelinOp)

OpenFHE relinearize operation of a ciphertext.

Syntax:

operation ::= `openfhe.relin` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.rot (heir::openfhe::RotOp)

Syntax:

operation ::= `openfhe.rot` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

openfhe.square (heir::openfhe::SquareOp)

OpenFHE square operation of a ciphertext.

Syntax:

operation ::= `openfhe.square` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

openfhe.sub (heir::openfhe::SubOp)

OpenFHE sub operation of two ciphertexts.

Syntax:

operation ::= `openfhe.sub` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

3.8 - PolyExt

The PolyExt dialect is a place for “external” operations on mlir::polynomial::Polynomial.

PolyExt ops

poly_ext.cmod_switch (heir::poly_ext::CModSwitchOp)

Move polynomial into a ring with different cmod by scaling polynomial coefficients proportionally

Syntax:

operation ::= `poly_ext.cmod_switch` $x attr-dict `:` type($x) `->` type($output)

poly_ext.cmod_switch “moves” polynomial $x$ from ring $Z/QZ[X]/(f(x))$ to the ring $Z/qZ[X]/(f(x))$. The move is done by scaling the polynomial coefficients by $q/Q$ and “rounding” so input and output coefficients are congruent modulo congruence_modulus $t$. The resulting polynomial $\tilde{x} \approx (q/Q)x$ and $\tilde{x} \equiv x \mod t$.

Traits: AlwaysSpeculatableImplTrait, Elementwise, Scalarizable, Tensorizable, Vectorizable

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

3.9 - Polynomial

Polynomial additional definitions

3.10 - RNS

RNS types

RNSType

A residue number system representation

Syntax:

!rns.rns<
  ::llvm::ArrayRef<mlir::Type>   # basisTypes
>

Parameters:

RNS ops

RNS additional definitions

TypeInterface definitions

RNSBasisTypeInterface (RNSBasisTypeInterface)

This interface is required for a type to be used as a parameter to an rns type.

Methods:

isCompatibleWith

bool isCompatibleWith(::mlir::Type otherRnsBasisType);

Returns true if this type is compatible with another type in the same RNS basis. In particular, the set of types used for a single RNS basis are never equal as types, but instead have some common attribute that must be checked here. For example, an RNS type where the basis types are polynomials would return true if the two types are both polynomial types, even if they have different coefficient moduli.

isCompatibleWith must be both commutative and associative, in the sense that type1.isCompatibleWith(type2) if and only if type2.isCompatibleWith(type1), and further type2.isCompatibleWith(type3) if and only if type1.isCompatibleWith(type3).

NOTE: This method must be implemented by the user.

3.11 - Secret

Secret is a dialect for computations that operate on encrypted data.

Secret is intended to serve as a scheme-agnostic front-end for the HEIR ecosystem of dialects. It is supposed to be fully interoperable with the rest of MLIR via secret.generic, while lower-level HEIR dialects would have custom types for arithmetic on secret integers of various bit widths.

Secret types

SecretType

A secret value

Syntax:

!secret.secret<
  Type   # valueType
>

A generic wrapper around another MLIR type, representing an encrypted value but not specifying the manner of encryption. This is useful in HEIR because the compiler may choose various details of the FHE scheme based on the properties of the input program, the backend target hardware, and cost models of the various passes.

Parameters:

Secret ops

secret.cast (heir::secret::CastOp)

A placeholder cast from one secret type to another

Syntax:

operation ::= `secret.cast` $input attr-dict `:` qualified(type($input)) `to` qualified(type($output))

A cast operation represents a type cast from one secret type to another, that is used to enable the intermixing of various equivalent secret types before a lower-level FHE scheme has been chosen.

For example, secret.cast can be used to convert a secret<i8> to a secret<tensor<8xi1>> as a compatibility layer between boolean and non-boolean parts of a program. The pass that later lowers the IR to specific FHE schemes would need to replace these casts with appropriate scheme-specific operations, and it is left to those later passes to determine which casts are considered valid.

Example:

%result = secret.cast %0 : !secret.secret<i8> to !secret.secret<tensor<8xi1>>
%result2 = secret.cast %0 : !secret.secret<i8> to !secret.secret<tensor<2xi4>>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

secret.conceal (heir::secret::ConcealOp)

Convert a non-secret value into a secret

Syntax:

operation ::= `secret.conceal` $cleartext attr-dict `:` type($cleartext) `->` type($output)

Convert a value to a secret containing the same value.

This op represents a scheme-agnostic encryption operation, as well as a “trivial encryption” operation which is needed for some FHE schemes. This op is also useful for type materialization in the dialect conversion framework.

Examples:

%Y = secret.conceal %value : i32 -> !secret.secret<i32>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

secret.generic (heir::secret::GenericOp)

Lift a plaintext computation to operate on secrets.

secret.generic lifts a plaintext computation to operate on one or more secrets. The lifted computation is represented as a region containing a single block terminated by secret.yield. The arguments of the secret.generic may include one or more !secret.secret types. The arguments of the block in the op’s body correspond to the underlying plaintext types of the secrets.

secret.generic is not isolated from above, so you may directly reference values in the enclosing scope. This is required to support using secret.generic inside of ops with AffineScope, while having the body of the generic use the induction variables defined by the affine scope.

Basic examples:

Add two secret integers together

%Z = secret.generic ins(%X, %Y : !secret.secret<i32>, !secret.secret<i32>) {
  ^bb0(%x: i32, %y: i32):
    %z = arith.addi %x, %y: i32
    secret.yield %z : i32
  } -> (!secret.secret<i32>)

Add a secret value with a plaintext value. I.e., not all arguments to the op need be secret.

%Z = secret.generic ins(%X, %Y : i32, !secret.secret<i32>) {
  ^bb0(%x: i32, %y: i32):
    %z = arith.addi %x, %y: i32
    secret.yield %z : i32
  } -> (!secret.secret<i32>)

The same as above, but the plaintext op is not passed through the basic block.

%y = arith.constant 7: i32
%Z = secret.generic ins(%Y : !secret.secret<i32>) {
  ^bb0(%y: i32):
    %z = arith.addi %x, %y: i32
    secret.yield %z : i32
  } -> (!secret.secret<i32>)

Traits: SingleBlockImplicitTerminator<YieldOp>, SingleBlock

Operands:

Results:

secret.reveal (heir::secret::RevealOp)

Convert a secret value into a non-secret

Syntax:

operation ::= `secret.reveal` $input attr-dict `:` type($input) `->` type($cleartext)

Convert a secret into a non-secret containing the same value.

This op represents a scheme-agnostic decryption operation. This op is also useful for target materialization in the dialect conversion framework.

Examples:

%Y = secret.reveal %secret_value : !secret.secret<i32> -> i32

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

secret.separator (heir::secret::SeparatorOp)

Convert a non-secret value into a secret

Syntax:

operation ::= `secret.separator` attr-dict ($inputs^ `:` type($inputs))?

This operation is used as a separation boundary between logical subunits of the module. This is used in conjunction with --secret-distribute-generic=distribute-through=secret.separator to break a generic around these separators and allow for optimization passses to analyze and optimize the sub-units locally.

In order to allow bufferization of modules with this operation, we must register a (bogus) memory effect that also prevents this operation from being trivially dead during operation folding.

This operation also accepts operands, which act as boundaries between the logical units. This enforces separation of memref and affine optimizations between the subunits, preventing optimizations from removing the operand and combining the two separated regions. The operand can be thought of as an return value of the logical subunit.

Interfaces: MemoryEffectOpInterface (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{MemoryEffects::Write on ::mlir::SideEffects::DefaultResource}

Operands:

secret.yield (heir::secret::YieldOp)

Secret yield operation

secret.yield is a special terminator operation for blocks inside regions in secret generic ops. It returns the cleartext value of the corresponding private computation to the immediately enclosing secret generic op.

Traits: AlwaysSpeculatableImplTrait, HasParent<GenericOp>, ReturnLike, Terminator

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), RegionBranchTerminatorOpInterface

Effects: MemoryEffects::Effect{}

Operands:

3.12 - TensorExt

TensorExt attributes

SIMDPackingAttr

An attribute describing the SIMD packing of a tensor.

Syntax:

#tensor_ext.simd_packing<
  ::mlir::DenseI64ArrayAttr,   # in
  ::mlir::DenseI64ArrayAttr,   # padding
  ::mlir::DenseI64ArrayAttr,   # out
  int64_t   # padding_value
>

This attribute is used as the encoding attribute on a tensor. It describes the transformations that were applied to an input tensor to pack it into the given tensor.

The in attribute describes the shape of the original tensor. The following transformations are applied to the input tensor.

1. Padding is applied first. The padding attribute is an array with the same size as the input tensor shape. Padding is applied at the end of the array using the padding_value attribute (default zero). The result after zero padding should be a power of two.

2. The padded result is replicated or split to fill the output tensor shape.

For example,

#packing = #tensor_ext.simd_packing<
  in = [7],
  padding = [1],
  padding_value = 0,
  out = [16],
>

may be used on a tensor type like

tensor<1x16xi32, #packing>

If the original tensor had values [1, 2, 3, 4, 5, 6, 7] then a tensor with this attribute contains the data [1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 0].

Parameters:

TensorExt ops

tensor_ext.rotate (heir::tensor_ext::RotateOp)

Rotate a tensor some number of indices left.

Syntax:

operation ::= `tensor_ext.rotate` operands attr-dict `:` qualified(type($tensor)) `,` type($shift)

This op represents a left-rotation of a tensor by given number of indices. Negative shift values are interpreted as right-rotations.

This corresponds to the rotate operation in arithmetic FHE schemes like BGV.

Examples:

%0 = ... : tensor<16xi32>
%c7 = arith.constant 7 : i32
%1 = tensor_ext.rotate %0, %c7 : tensor<16xi32>, i32

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

3.13 - TfheRust

The thfe_rust dialect is an exit dialect for generating rust code against the tfhe-rs library API, using the shortint parameters and encoding scheme.

See https://github.com/zama-ai/tfhe-rs

TfheRust types

EncryptedInt8Type

An encrypted signed integer corresponding to tfhe-rs’s FHEInt8 type

Syntax: !tfhe_rust.ei8

EncryptedInt16Type

An encrypted signed integer corresponding to tfhe-rs’s FHEInt16 type

Syntax: !tfhe_rust.ei16

EncryptedInt32Type

An encrypted signed integer corresponding to tfhe-rs’s FHEInt32 type

Syntax: !tfhe_rust.ei32

EncryptedInt64Type

An encrypted signed integer corresponding to tfhe-rs’s FHEInt64 type

Syntax: !tfhe_rust.ei64

EncryptedInt128Type

An encrypted signed integer corresponding to tfhe-rs’s FHEInt128 type

Syntax: !tfhe_rust.ei128

EncryptedInt256Type

An encrypted signed integer corresponding to tfhe-rs’s FHEInt256 type

Syntax: !tfhe_rust.ei256

EncryptedUInt2Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint2 type

Syntax: !tfhe_rust.eui2

EncryptedUInt3Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint3 type

Syntax: !tfhe_rust.eui3

EncryptedUInt4Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint4 type

Syntax: !tfhe_rust.eui4

EncryptedUInt8Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint8 type

Syntax: !tfhe_rust.eui8

EncryptedUInt10Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint10 type

Syntax: !tfhe_rust.eui10

EncryptedUInt12Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint12 type

Syntax: !tfhe_rust.eui12

EncryptedUInt14Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint14 type

Syntax: !tfhe_rust.eui14

EncryptedUInt16Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint16 type

Syntax: !tfhe_rust.eui16

EncryptedUInt32Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint32 type

Syntax: !tfhe_rust.eui32

EncryptedUInt64Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint64 type

Syntax: !tfhe_rust.eui64

EncryptedUInt128Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint128 type

Syntax: !tfhe_rust.eui128

EncryptedUInt256Type

An encrypted unsigned integer corresponding to tfhe-rs’s FHEUint256 type

Syntax: !tfhe_rust.eui256

LookupTableType

A univariate lookup table used for programmable bootstrapping.

Syntax: !tfhe_rust.lookup_table

ServerKeyType

The short int server key required to perform homomorphic operations.

Syntax: !tfhe_rust.server_key

TfheRust ops

tfhe_rust.apply_lookup_table (heir::tfhe_rust::ApplyLookupTableOp)

Syntax:

operation ::= `tfhe_rust.apply_lookup_table` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust.create_trivial (heir::tfhe_rust::CreateTrivialOp)

Syntax:

operation ::= `tfhe_rust.create_trivial` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust.generate_lookup_table (heir::tfhe_rust::GenerateLookupTableOp)

Syntax:

operation ::= `tfhe_rust.generate_lookup_table` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

tfhe_rust.scalar_left_shift (heir::tfhe_rust::ScalarLeftShiftOp)

Syntax:

operation ::= `tfhe_rust.scalar_left_shift` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust.add (heir::tfhe_rust::AddOp)

Arithmetic add of two tfhe ciphertexts.

Syntax:

operation ::= `tfhe_rust.add` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust.bitand (heir::tfhe_rust::BitAndOp)

Logical AND of two tfhe ciphertexts.

Syntax:

operation ::= `tfhe_rust.bitand` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust.sub (heir::tfhe_rust::SubOp)

Arithmetic sub of two tfhe ciphertexts.

Syntax:

operation ::= `tfhe_rust.sub` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

3.14 - TfheRustBool

The tfhe_rust_bool dialect is an exit dialect for generating rust code against the tfhe-rs library API, using the boolean parameter set.

See https://github.com/zama-ai/tfhe-rs

TfheRustBool types

EncryptedBoolType

An encrypted Boolean corresponding to tfhe-rs’s FHEBool type

Syntax: !tfhe_rust_bool.eb

ServerKeyType

The boolean server key required to perform homomorphic operations.

Syntax: !tfhe_rust_bool.server_key

TfheRustBool ops

tfhe_rust_bool.and (heir::tfhe_rust_bool::AndOp)

Logical AND of two TFHE-rs Bool ciphertexts.

Syntax:

operation ::= `tfhe_rust_bool.and` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.create_trivial (heir::tfhe_rust_bool::CreateTrivialOp)

Syntax:

operation ::= `tfhe_rust_bool.create_trivial` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.mux (heir::tfhe_rust_bool::MuxOp)

Syntax:

operation ::= `tfhe_rust_bool.mux` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.nand (heir::tfhe_rust_bool::NandOp)

Logical NAND of two TFHE-rs Bool ciphertexts.

Syntax:

operation ::= `tfhe_rust_bool.nand` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.nor (heir::tfhe_rust_bool::NorOp)

Logical NOR of two TFHE-rs Bool ciphertexts.

Syntax:

operation ::= `tfhe_rust_bool.nor` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.not (heir::tfhe_rust_bool::NotOp)

Syntax:

operation ::= `tfhe_rust_bool.not` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.or (heir::tfhe_rust_bool::OrOp)

Logical OR of two TFHE-rs Bool ciphertexts.

Syntax:

operation ::= `tfhe_rust_bool.or` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.xnor (heir::tfhe_rust_bool::XnorOp)

Logical XNOR of two TFHE-rs Bool ciphertexts.

Syntax:

operation ::= `tfhe_rust_bool.xnor` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

tfhe_rust_bool.xor (heir::tfhe_rust_bool::XorOp)

Logical XOR of two TFHE-rs Bool ciphertexts.

Syntax:

operation ::= `tfhe_rust_bool.xor` operands attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Results:

4 - Passes

This section contains the passes defined by HEIR.

4.1 - ApplyFoldersPasses

-apply-folders

Apply all folding patterns from canonicalize

This pass applies all registered folding patterns greedily to the input IR. This is useful when running a full canonicalize is too slow, but applying folders before canonicalize is sufficient to simplify the IR for later passes, or even sufficient to then subsequently run a full canonicalize pass.

This is used to prepare an IR for insert-rotate after fully unrolling loops.

4.2 - BGVPasses

-bgv-add-client-interface

Add client interfaces to BGV encrypted functions

This pass adds encrypt and decrypt functions for each compiled function in the IR. These functions maintain the same interface as the original function, while the compiled function may lose some of this information by the lowerings to ciphertext types (e.g., a scalar ciphertext, when lowered through BGV, must be encoded as a tensor).

Example:

For an input function with signature

#encoding = ...
#params = ...
!in_ty = !lwe.rlwe_ciphertext<encoding = #encoding, rlwe_params = #params, underlying_type = tensor<32xi16>>
!out_ty = !lwe.rlwe_ciphertext<encoding = #encoding, rlwe_params = #params, underlying_type = i16>
func.func @my_func(%arg0: !in_ty) -> !out_ty {
  ...
}

The pass will generate two new functions with signatures

func.func @my_func__encrypt(
  %arg0: tensor<32xi16>,
  %sk: !lwe.rlwe_secret_key<...>
) -> !in_ty

func.func @my_func__decrypt(
  %arg0: !out_ty,
  %sk: !lwe.rlwe_secret_key<...>
) -> i16

The my_func__encrypt function has the same order of operands as my_func, and uses their underylying_type as the corresponding input type. The last operand is the encryption key. The same holds for my_func__decrypt, but the inputs are the return types of my_func and the results are the underlying types of the return types of my_func.

If use-public-key is set to true, the encrypt function uses lwe.rlwe_public_key for encryption.

If one-value-per-helper-fn is set to true, the encryption helpers are split into separate functions, one for each SSA value being converted. For example, using the same !in_ty and !out_ty as above, this function signature

func.func @my_func(%arg0: !in_ty, %arg1: !in_ty) -> (!out_ty, !out_ty)

generates the following four helpers.

func.func @my_func__encrypt__arg0(%arg0: tensor<32xi16>, %sk: !lwe.rlwe_secret_key<...>) -> !in_ty
func.func @my_func__encrypt__arg1(%arg1: tensor<32xi16>, %sk: !lwe.rlwe_secret_key<...>) -> !in_ty
func.func @my_func__decrypt__result0(%arg0: !out_ty, %sk: !lwe.rlwe_secret_key<...>) -> i16
func.func @my_func__decrypt__result1(%arg1: !out_ty, %sk: !lwe.rlwe_secret_key<...>) -> i16
}

The suffix __argN indicates the SSA value being encrypted is the N-th argument of my_func, and similarly for __resultN.

Options

-use-public-key          : If true, generate a client interface that uses a public key for encryption.
-one-value-per-helper-fn : If true, split encryption helpers into separate functions for each SSA value.

4.3 - BGVToOpenfhe

-bgv-to-openfhe

Lower bgv to openfhe dialect.

This pass lowers the bgv dialect to Openfhe dialect.

4.4 - BGVToPolynomial

-bgv-to-polynomial

Lower bgv to polynomial dialect.

This pass lowers the bgv dialect to polynomial dialect.

4.5 - CGGIPasses

-cggi-set-default-parameters

Set default parameters for CGGI ops

This pass adds default parameters to all CGGI ops as cggi_params named attributes, overriding any existing attribute set with that name.

This pass is primarily for testing purposes, and as a parameter provider before a proper parameter selection mechanism is added. This pass should not be used in production.

The specific parameters are hard-coded in lib/Dialect/CGGI/Transforms/SetDefaultParameters.cpp.

4.6 - CGGIToTfheRust

-cggi-to-tfhe-rust

Lower cggi to tfhe_rust dialect.

4.7 - CGGIToTfheRustBool

-cggi-to-tfhe-rust-bool

Lower cggi to tfhe_rust_bool dialect.

4.8 - CombToCGGI

-comb-to-cggi

Lower comb to cggi dialect.

This pass lowers the comb dialect to cggi dialect.

4.9 - ConvertIfToSelectPasses

-convert-if-to-select

Convert scf.if operations on secret conditions to arith.select operations.

Conversion for If-operations that evaluate secret condition to alternative select operations.

4.10 - ElementwiseToAffinePasses

-convert-elementwise-to-affine

This pass lowers ElementwiseMappable operations to Affine loops.

This pass lowers ElementwiseMappable operations over tensors to affine loop nests that instead apply the operation to the underlying scalar values.

4.11 - ForwardStoreToLoadPasses

-forward-store-to-load

Forward stores to loads within a single block

This pass is a simplified version of mem2reg and similar passes. It analyzes an operation, finding all basic blocks within that op that have memrefs whose stores can be forwarded to loads.

Does not support complex control flow within a block, nor ops with arbitrary subregions.

4.12 - FullLoopUnrollPasses

-full-loop-unroll

Fully unroll all loops

Scan the IR for affine.for loops and unroll them all.

4.13 - LWEPasses

-lwe-set-default-parameters

Set default parameters for LWE ops

This pass adds default parameters to all lwe types as the lwe_params attribute, and for lwe ops as the params attribute, overriding any existing attributes set with those names.

This pass is primarily for testing purposes, and as a parameter provider before a proper parameter selection mechanism is added. This pass should not be used in production.

The specific parameters are hard-coded in lib/Dialect/LWE/Transforms/SetDefaultParameters.cpp.

4.14 - LWEToPolynomial

-lwe-to-polynomial

Lower lwe to polynomial dialect.

This pass lowers the lwe dialect to polynomial dialect.

4.15 - MemrefToArith

-expand-copy

Expands memref.copy ops to explicit affine loads and stores

This pass removes memref copy operations by expanding them to affine loads and stores. This pass introduces affine loops over the dimensions of the MemRef, so must be run prior to any affine loop unrolling in a pipeline.

Input

module {
  func.func @memref_copy() {
    %alloc = memref.alloc() : memref<2x3xi32>
    %alloc_0 = memref.alloc() : memref<2x3xi32>
    memref.copy %alloc, %alloc_0 : memref<1x1xi32> to memref<1x1xi32>
  }
}

Output

module {
  func.func @memref_copy() {
    %alloc = memref.alloc() : memref<2x3xi32>
    %alloc_0 = memref.alloc() : memref<2x3xi32>
    affine.for %arg0 = 0 to 2 {
      affine.for %arg1 = 0 to 3 {
        %1 = affine.load %alloc[%arg0, %arg1] : memref<2x3xi32>
        affine.store %1, %alloc_0[%arg0, %arg1] : memref<2x3xi32>
      }
    }
  }
}

When --disable-affine-loop=true is set, then the output becomes

module {
  func.func @memref_copy() {
    %alloc = memref.alloc() : memref<2x3xi32>
    %alloc_0 = memref.alloc() : memref<2x3xi32>
    %c0 = arith.constant 0 : index
    %c1 = arith.constant 1 : index
    %c2 = arith.constant 2 : index
    %0 = affine.load %alloc[%c0, %c0] : memref<2x3xi32>
    affine.store %0, %alloc_0[%c0, %c0] : memref<2x3xi32>
    %1 = affine.load %alloc[%c0, %c1] : memref<2x3xi32>
    affine.store %1, %alloc_0[%c0, %c1] : memref<2x3xi32>
    %2 = affine.load %alloc[%c0, %c2] : memref<2x3xi32>
    affine.store %2, %alloc_0[%c0, %c2] : memref<2x3xi32>
    [...]
  }
}

Options

-disable-affine-loop : Use this to control to disable using affine loops

-extract-loop-body

Extracts logic of a loop bodies into functions.

This pass extracts logic in the inner body of for loops into functions.

This pass requires that tensors are lowered to memref. It expects that a loop body contains a number of affine.load statements used as inputs to the extracted function, and a single affine.store used as the extracted function’s output.

Input

module {
  func.func @loop_body() {
    %c-128_i8 = arith.constant -128 : i8
    %c127_i8 = arith.constant 127 : i8
    %alloc_7 = memref.alloc() {alignment = 64 : i64} : memref<25x20x8xi8>
    affine.for %arg1 = 0 to 25 {
      affine.for %arg2 = 0 to 20 {
        affine.for %arg3 = 0 to 8 {
          %98 = affine.load %alloc_6[%arg1, %arg2, %arg3] : memref<25x20x8xi8>
          %99 = arith.cmpi slt, %arg0, %c-128_i8 : i8
          %100 = arith.select %99, %c-128_i8, %arg0 : i8
          %101 = arith.cmpi sgt, %arg0, %c127_i8 : i8
          %102 = arith.select %101, %c127_i8, %100 : i8
          affine.store %102, %alloc_7[%arg1, %arg2, %arg3] : memref<25x20x8xi8>
        }
      }
    }
  }
}

Output

module {
  func.func @loop_body() {
    %alloc_7 = memref.alloc() {alignment = 64 : i64} : memref<25x20x8xi8>
    affine.for %arg1 = 0 to 25 {
      affine.for %arg2 = 0 to 20 {
        affine.for %arg3 = 0 to 8 {
          %98 = affine.load %alloc_6[%arg1, %arg2, %arg3] : memref<25x20x8xi8>
          %102 = func.call @__for_loop(%98) : (i8) -> i8
          affine.store %102, %alloc_7[%arg1, %arg2, %arg3] : memref<25x20x8xi8>
        }
      }
    }
  }
  func.func private @__for_loop(%arg0: i8) -> i8 {
    %c-128_i8 = arith.constant -128 : i8
    %c127_i8 = arith.constant 127 : i8
    %99 = arith.cmpi slt, %arg0, %c-128_i8 : i8
    %100 = arith.select %99, %c-128_i8, %arg0 : i8
    %101 = arith.cmpi sgt, %arg0, %c127_i8 : i8
    %102 = arith.select %101, %c127_i8, %100 : i8
    return %102 : i8
  }
}

Options

-min-loop-size : Use this to control the minimum loop size to apply this pass
-min-body-size : Use this to control the minimum loop body size to apply this pass

-memref-global-replace

MemrefGlobalReplacePass forwards global memrefs accessors to arithmetic values

This pass forwards constant global MemRef values to referencing affine loads. This pass requires that the MemRef global values are initialized as constants and that the affine load access indices are constants (i.e. not variadic). Unroll affine loops prior to running this pass.

MemRef removal is required to remove any memory allocations from the input model (for example, TensorFlow models contain global memory holding model weights) to support FHE transpilation.

Input

module {
  memref.global "private" constant @__constant_8xi16 : memref<2x4xi16> = dense<[[-10, 20, 3, 4], [5, 6, 7, 8]]>
  func.func @main() -> i16 {
    %c1 = arith.constant 1 : index
    %c2 = arith.constant 2 : index
    %0 = memref.get_global @__constant_8xi16 : memref<2x4xi16>
    %1 = affine.load %0[%c1, %c1 + %c2] : memref<2x4xi16>
    return %1 : i16
  }
}

Output

module {
  func.func @main() -> i16 {
    %c1 = arith.constant 1 : index
    %c2 = arith.constant 2 : index
    %c8_i16 = arith.constant 8 : i16
    return %c8_i16 : i16
  }
}

-unroll-and-forward

Loop unrolls and forwards stores to loads.

This pass processes the first function in a given module, and, starting from the first loop, iteratively does the following:

1. Fully unroll the loop.
2. Scan for load ops. For each load op with a statically-inferrable access index:
3. Backtrack to the original memref alloc
4. Find all store ops at the corresponding index (possibly transitively through renames/subviews of the underlying alloc).
5. Find the last store that occurs and forward it to the load.
6. If the original memref is an input memref, then forward through any renames to make the target load load directly from the argument memref (instead of any subviews, say)
7. Apply the same logic to any remaining loads not inside any for loop.

This pass requires that tensors are lowered to memref, and only supports affine loops with affine.load/store ops.

Memrefs that result from memref.get_global ops are excluded from forwarding, even if they are loaded with a static index, and are instead handled by memref-global-replace, which should be run after this pass.

4.16 - OpenfhePasses

-openfhe-configure-crypto-context

Configure the crypto context in OpenFHE

This pass generates helper functions to generate and configure the OpenFHE crypto context for the given function. Generating the crypto context sets the appropriate encryption parameters, while the configuration generates the necessary evaluation keys (relinearization and rotation keys).

For example, for an MLIR function @my_func, the generated helpers have the following signatures

func.func  @my_func__generate_crypto_context() -> !openfhe.crypto_context

func.func  @my_func__configure_crypto_context(!openfhe.crypto_context, !openfhe.private_key) -> !openfhe.crypto_context

Options

-entry-function : Default entry function name of entry function.

4.17 - PolynomialPasses

-convert-polynomial-mul-to-ntt

Rewrites polynomial operations to their NTT equivalents

Applies a rewrite pattern to convert polynomial multiplication to the equivalent using the number-theoretic transforms (NTT) when possible.

Polynomial multiplication can be rewritten as polynomial.NTT on each operand, followed by modulo elementwise multiplication of the point-value representation and then the inverse-NTT back to coefficient representation.

4.18 - PolynomialToStandard

-polynomial-to-standard

Lower polynomial to standard MLIR dialects.

This pass lowers the polynomial dialect to standard MLIR, a mixture of affine, tensor, and arith.

4.19 - SecretizePasses

-secretize

Adds secret argument attributes to entry function

Adds a secret.secret attribute argument to each argument in the entry function of an MLIR module. By default, the function is main. This may be overridden with the option -entry-function=top_level_func.

Options

-entry-function : entry function of the module

-wrap-generic

Wraps regions using secret args in secret.generic bodies

This pass wraps function regions of func.func that use secret arguments in secret.generic bodies.

Secret arguments are annotated using a secret.secret argument attribute. This pass converts these to secret types and then inserts a secret.generic body to hold the functions region. The output type is also converted to a secret.

Example input:

  func.func @main(%arg0: i32 {secret.secret}) -> i32 {
    %0 = arith.constant 100 : i32
    %1 = arith.addi %0, %arg0 : i32
    return %1 : i32
  }

Output:

  func.func @main(%arg0: !secret.secret<i32>) -> !secret.secret<i32> {
    %0 = secret.generic ins(%arg0 : !secret.secret<i32>) {
    ^bb0(%arg1: i32):
      %1 = arith.constant 100 : i32
      %2 = arith.addi %0, %arg1 : i32
      secret.yield %2 : i32
    } -> !secret.secret<i32>
    return %0 : !secret.secret<i32>
  }

4.20 - SecretPasses

-secret-capture-generic-ambient-scope

Capture the ambient scope used in a secret.generic

For each value used in the body of a secret.generic op, which is defined in the ambient scope outside the generic, add it to the argument list of the generic.

-secret-distribute-generic

Distribute generic ops through their bodies.

Converts generic ops whose region contains many ops into smaller sequences of generic ops whose regions contain a single op, dropping the generic part from any resulting generic ops that have no secret.secret inputs. If the op has associated regions, and the operands are not secret, then the generic is distributed recursively through the op’s regions as well.

This pass is intended to be used as part of a front-end pipeline, where a program that operates on a secret type annotates the input to a region as secret, and then wraps the contents of the region in a single large secret.generic, then uses this pass to simplify it.

The distribute-through option allows one to specify a comma-separated list of op names (e.g., distribute-thorugh="affine.for,scf.if"), which limits the distribution to only pass through those ops. If unset, all ops are distributed through when possible.

Options

-distribute-through : comma-separated list of ops that should be distributed through

-secret-extract-generic-body

Extract the bodies of all generic ops into functions

This pass extracts the body of all generic ops into functions, and replaces the generic bodies with call ops. Used as a sub-operation in some passes, and extracted into its own pass for testing purposes.

This pass works best when --secret-generic-absorb-constants is run before it so that the extracted function contains any constants used in the generic op’s body.

-secret-forget-secrets

Convert secret types to standard types

Drop the secret<...> type from the IR, replacing it with the contained type and the corresponding cleartext computation.

-secret-generic-absorb-constants

Copy constants into a secret.generic body

For each constant value used in the body of a secret.generic op, which is defined in the ambient scope outside the generic, add it’s definition into the generic body.

-secret-generic-absorb-dealloc

Copy deallocs of internal memrefs into a secret.generic body

For each memref allocated and used only within a body of a secret.generic op, add it’s dealloc of the memref into its generic body.

-secret-merge-adjacent-generics

Merge two adjacent generics into a single generic

This pass merges two immedaitely sequential generics into a single generic. Useful as a sub-operation in some passes, and extracted into its own pass for testing purposes.

4.21 - SecretToBGV

-secret-to-bgv

Lower secret to bgv dialect.

This pass lowers an IR with secret.generic blocks containing arithmetic operations to operations on ciphertexts with the BGV dialect.

The pass assumes that the secret.generic regions have been distributed through arithmetic operations so that only one ciphertext operation appears per generic block. It also requires that canonicalize was run so that non-secret values used are removed from the secret.generic’s block arguments.

The pass requires that all types are tensors of a uniform shape matching the dimension of the ciphertext space specified my poly-mod-degree.

Options

-poly-mod-degree      : Default degree of the cyclotomic polynomial modulus to use for ciphertext space.
-coefficient-mod-bits : Default number of bits of the prime coefficient modulus to use for the ciphertext space.

4.22 - StraightLineVectorizerPasses

-straight-line-vectorize

A vectorizer for straight line programs.

This pass ignores control flow and only vectorizes straight-line programs within a given region.

Options

-dialect : Use this to restrict the dialect whose ops should be vectorized.

4.23 - TensorExtPasses

-align-tensor-sizes

Resize tensors into tensors with a fixed size final dimension

This pass resizes input tensors with arbitrary sizes into tensors with whose final dimensions has a fixed size. All input tensors are required to be one-dimensional. The --size option specifies the size of the final dimension of the output tensors, and is required to be a power of two.

To align the tensors in the input IR, the pass first zero pads the input to the nearest power of two before replicating or splitting it into the output shape determined by size. The resulting transformation is described in a SIMDPackingAttr encoding attribute on the final tensor.

For example, with size=16,a tensor with 7 elements will be zero-padded to 8 elements, and then replicated twice to fill a tensor with size 16. The SIMDPackingAttr will encode the input shape, the number of elements that were zero-padded, and the output shape.

Input:

%0 = tensor.empty() : tensor<7xi32>

Output:

%0 = tensor.empty() : tensor<16xi32, #tensor_ext.simd_packing<in = [7], padding = [1], out = [16]>>

A tensor with 30 elements will be zero padded with 2 elements and split into two tensors of size 16.

Input:

%0 = tensor.empty() : tensor<30xi32>

Output:

%0 = tensor.empty() : tensor<2x16xi32, #tensor_ext.simd_packing<in = [30], padding = [2], out = [16]>>

Note that this pass does not insert any new operations like reshape, but rather transforms the IR to use tensors with a fixed dimension. This pass may be used to align the sizes of tensors that represent plaintexts and ciphertexts in RLWE schemes that support SIMD slots and operations.

Options

-size : Power of two size of the final dimension of the output tensors.

-collapse-insertion-chains

Collapse chains of extract/insert ops into rotate ops when possible

This pass is a cleanup pass for insert-rotate. That pass sometimes leaves behind a chain of insertion operations like this:

%extracted = tensor.extract %14[%c5] : tensor<16xi16>
%inserted = tensor.insert %extracted into %dest[%c0] : tensor<16xi16>
%extracted_0 = tensor.extract %14[%c6] : tensor<16xi16>
%inserted_1 = tensor.insert %extracted_0 into %inserted[%c1] : tensor<16xi16>
%extracted_2 = tensor.extract %14[%c7] : tensor<16xi16>
%inserted_3 = tensor.insert %extracted_2 into %inserted_1[%c2] : tensor<16xi16>
...
%extracted_28 = tensor.extract %14[%c4] : tensor<16xi16>
%inserted_29 = tensor.insert %extracted_28 into %inserted_27[%c15] : tensor<16xi16>
yield %inserted_29 : tensor<16xi16>

In many cases, this chain will insert into every index of the dest tensor, and the extracted values all come from consistently aligned indices of the same source tensor. In this case, the chain can be collapsed into a single rotate.

Each index used for insertion or extraction must be constant; this may require running --canonicalize or --sccp before this pass to apply folding rules (use --sccp if you need to fold constant through control flow).

-insert-rotate

Vectorize arithmetic FHE operations using HECO-style heuristics

This pass implements the SIMD-vectorization passes from the HECO paper.

The pass operates by identifying arithmetic operations that can be suitably combined into a combination of cyclic rotations and vectorized operations on tensors. It further identifies a suitable “slot target” for each operation and heuristically aligns the operations to reduce unnecessary rotations.

This pass by itself does not eliminate any operations, but instead inserts well-chosen rotations so that, for well-structured code (like unrolled affine loops), a subsequent --cse and --canonicalize pass will dramatically reduce the IR. As such, the pass is designed to be paired with the canonicalization patterns in tensor_ext, as well as the collapse-insertion-chains pass, which cleans up remaining insertion and extraction ops after the main simplifications are applied.