openfhe: add bootstrap op

[ZenithalHourlyRate]

This follows the setup step in simple-ckks-bootstrapping example in OpenFHE.

With input

  func.func @func(%arg0: !openfhe.crypto_context, %arg1: !rlwe_ct_L0_) -> !rlwe_ct_L0_ {
    %0 = openfhe.bootstrap %arg0, %arg1 : (!openfhe.crypto_context, !rlwe_ct_L0_) -> !rlwe_ct_L0_
    return %0 : !rlwe_ct_L0_
  }

with --openfhe-configure-crypto-context we get

  func.func @func__generate_crypto_context() -> !openfhe.crypto_context {
    %0 = openfhe.gen_params  {mulDepth = 20 : i64, plainMod = 4295294977 : i64} : () -> !openfhe.cc_params
    %1 = openfhe.gen_context %0 {supportFHE = true} : (!openfhe.cc_params) -> !openfhe.crypto_context
    return %1 : !openfhe.crypto_context
  }
  func.func @func__configure_crypto_context(%arg0: !openfhe.crypto_context, %arg1: !openfhe.private_key) -> !openfhe.crypto_context {
    openfhe.gen_mulkey %arg0, %arg1 : (!openfhe.crypto_context, !openfhe.private_key) -> ()
    openfhe.setup_bootstrap %arg0 {levelBudgetDecode = 3 : index, levelBudgetEncode = 3 : index} : (!openfhe.crypto_context) -> ()
    openfhe.gen_bootstrap_key %arg0, %arg1 : (!openfhe.crypto_context, !openfhe.private_key) -> ()
    return %arg0 : !openfhe.crypto_context
  }

Then the translated code can run with a main function similar to simple-ckks-bootstrap.

To make it run faster, the following setup step is needed

  v3.SetSecurityLevel(HEStd_NotSet);
  v3.SetRingDim(1 << 12);

Link the generated code against an OpenFHE with multi-thread support and fast math backend (HEIR internal one is single-thread, slow math backend). It could run within 3 second (96 core machine). Link against HEIR internal one would require about 2 minutes to run.

Discussion

• mulDepth is now interwined with bootstrap, hence all the RNS instantiation need to change. and CKKS: place mgmt ops and add RNS lowering #1176 way could not handle this. I think that would need introducing a mgmt.bootstrap op and implement a bootstrap management pass (possibly related to Investigate what parts of DaCapo can be ported to HEIR #289, Investigate if/how to integrate Saturn into HEIR #1166).
• Currently, the bootstrapDepth (level consumed by bootstrap) is hard-encoded with value taken from openfhe. This depth will affect logN selection hence slot num, which is needed by the EvalBootstrapKeyGen. Now I acquire this time in runtime (by the emitter) from cryptoContext instead of putting it in openfhe.gen_bootstrap_key op.

[ZenithalHourlyRate]

Rebased to new lwe type. Tests will be added later.

[AlexanderViand-Intel]

Link the generated code against an OpenFHE with multi-thread support and fast math backend (HEIR internal one is single-thread, slow math backend). It could run within 3 second (96 core machine). Link against HEIR internal one would require about 2 minutes to run.

Are there any downsides to building OpenFHE with OpenMP and a fast math backend (apart from adding additional dependencies, I guess?). If no, then we should consider doing so as the internal default, especially if people indeed end up using HEIR for benchmarking.

I think that would need introducing a mgmt.bootstrap op

In general, I think it's fine to add low-level operations that the high-level parts of the compiler don't know how to generate (a lot better than the reverse, at least). However, I feel like it'd be nice to also add ckks.bootstrap and the lowering to openfhe, so that one could at least write "hand-managed" code at the CKKS level (would probably also make for nicer tests)

[ZenithalHourlyRate]

I feel like it'd be nice to also add ckks.bootstrap and the lowering to openfhe,

Definitely.

Now the e2e test is added. Check tests/Examples/openfhe/simple_ckks_bootstrapping_test.cpp. To make it run faster, I used insecure parameters, which is enabled by --openfhe-configure-crypto-context=entry-function=simple_ckks_bootstrapping insecure=true and it will SetRingDim(128). It now finishes in 3s.

building OpenFHE with OpenMP and a fast math backend (apart from adding additional dependencies, I guess?

I do agree we should integrate a fastest openfhe for proper evaluation, but that involves a lot of bazel (possibly needs jeremy).

Also, github actions CI is not super powerful so it won't benefit much from it. Instead I choose to use a smaller parameter for the testing pipeline and added a warning on the test on the insecurity for other people wanting to use it.

[j2kun]

Link the generated code against an OpenFHE with multi-thread support and fast math backend (HEIR internal one is single-thread, slow math backend). It could run within 3 second (96 core machine). Link against HEIR internal one would require about 2 minutes to run.

When I first set this up, the obstacle was the cmake indirection layer. I will file an issue.

[j2kun]

LGTM!!

[j2kun]

I think I will clean these up after this PR goes in, since we have a few implementations of "walk until you find fn(op)" in the codebase.

[j2kun]

There are some merge conflicts. If you don't have time to fix them I can do an internal patch tomorrow to resolve it.

[ZenithalHourlyRate]

Rebased.