Jeremy Kun

Another obstacle: ideally whatever modifies the input to resize things as appropriate for a particular FHE scheme must also provide an interface layer for the original code. I.e., if the...

Scratch that, I can get it to run the lowering, if I hard code the vector size as a pass parameter: ``` '--secretize=entry-function=linear_polynomial' --wrap-generic --canonicalize --cse --heir-simd-vectorizer --secret-distribute-generic '--secret-to-bgv=poly-mod-degree=64' ```...

Returning to this with the following outline: - Add a `bgv-add-client-interface` that adds encrypt/decrypt functions around the compiled entry function, so that we can preserve the coherence of the lowered...

Thinking out loud as I work through some of my issues lowering bgv.extract. Right now the `bgv.extract` op is asserting the input `underlying_type` on a ciphertext goes from a tensor...

An alternative is to introduce some sort of "cast" op that just changes the underlying type.

I will go with the `cast` approach, and now I'm realizing I also need to enhance `add-client-interface` to support public-key encryption, since that is what openfhe uses.

An e2e test ```mlir // RUN: heir-opt --mlir-to-openfhe-bgv-pipeline='entry-function=simple_sum ciphertext-degree=32' %s | FileCheck %s // CHECK-LABEL: @simple_sum // CHECK: openfhe func.func @simple_sum(%arg0: tensor) -> i16 { %c0 = arith.constant 0 :...

Remaining improvements are split into their own issues.

Love the idea. I'm not intimately familiar with the details of their work, but it seems like the first step would be to encode the tile tensor notation in the...

I'm going to start on the `secret` docs because it's what I have the energy to do right now.