google / google/heir

Infrastructure for comparisons with other compilers

Open
#2,326 0 comments 0 reactions 1 assignee Claimed by @j2kun View on GitHub
Dominant language
MLIR
Stars
906
Forks
171
Avg merge
4d 12h
Merged PRs (30d)
32

Description

We're starting up an effort to compare HEIR with other research compilers, and this ticket is meant to track infrastructure work related to that task, as well as be a place for discussion on the topic.

We want to compare with a few compilers in the literature, but for the sake of this ticket I will use Orion as the example.

There is an existing project thanks to @eymay that provides an initial Orion -> HEIR translation step, emitting CKKS dialect code (with some new ops needed by Orion but that the `ckks` dialect doesn't have). There are a few changes that need to be made to that project, which I will fork in https://github.com/j2kun/orion_heir_translator, but the general outline I want to establish for each compiler that wants to act as a frontend for HEIR:

1. Add a new entry dialect in HEIR that mirrors the output API of the frontend compiler. In our case it would be an `orion` dialect that includes a `linear_transform` operation and a `chebyshev` operation applied to ciphertexts.
2. Add a conversion pass that lowers from the entry dialect to the relevant HEIR dialect. For `orion` we'd lower to `ckks` dialect and would have to EITHER:
1. Implement `linear_transform` and `chebyshev` using existing HEIR methods, extracting the relevant subset of code to helpers or using interfaces. The downside of this method is that `linear_transform` would only get single-hoisting optimizations, as double-hoisting requires the backend lib to expose it (Lattigo does, OpenFHE does not) and HEIR won't have it until we finish implementing the crypto in the compiler.
2. Add separate ops in the chosen exit dialect (e.g., `lattigo.chebyshev`) and lower directly to those intsead of an intermediate `ckks` op. I am leaning against this option because (a) not all backends have APIs for these, and (b) this would preclude is from lowering from `orion` to `polynomial` when the crypto is implemented.
3. Lower from `ckks` further as normal.

So as the first part of this, I will add an `orion` dialect and lowerings.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.