Generate a helper that configures OpenFHE crypto context based on the IR content

[j2kun]

trafficstars

Right now the user must manually call functions like EvalMultKeyGen if the IR contains EvalMult, and EvalRotateKeyGen with known rotation shifts (which requires looking at the generated code to determine), as well as SetMultiplicativeDepth and SetPlaintextModulus.

We should have a pass in the OpenFHE dialect that generates a function that configures the cryptoContext appropriately.

[Maokami]

I've looked over this issue, and I would like to give it a try :) I'm currently preparing for my master's thesis defense, so I will probably be able to start it next Tuesday.

[asraa]

Also one more note: we can add the pub/priv key generation to the context generation function (https://github.com/google/heir/pull/696#discussion_r1636688307), if we remove the restriction to return only one value.

Maybe something like:

(context, pubkey, privkey) = my_func__generate_crypto_context()

or it could go in configure

[asraa]

After removing that restriction, we also can remove the return parameter in configure_crypto_context. See https://github.com/google/heir/pull/696#discussion_r1636695254

[Maokami]

https://github.com/google/heir/pull/696#issuecomment-2143834856

Now, I'm trying to determine the appropriate values for mulDepth and plainMod. My plan is as follows:

1. Finding mulDepth:

   • Determine the maximum multiplication depth through forward dataflow analysis.
   • muldepth(op) = max_i (muldepth(operand_i(op))) + 1 if op is mulOp (or mulPlainOp)
   • muldepth(op) = max_i (muldepth(operand_i(op))) otherwise

2. Finding plainMod:

   • Considering the following post (https://openfhe.discourse.group/t/automaticly-find-a-good-plaintext-modulus/312), I think the best approach is to determine the maximum number of plaintext bits (nBits) that can appear in the program and then call OpenFHE's FirstPrime(nBits, 2*65536) to calculate plainMod. To do this, it seems reasonable to receive the maximum plaintext bit count of the inputs given as arguments to the program and then use forward dataflow analysis to determine the maximum plaintext bits of the program.

Before I forget, I would like to seek some advice and explain what I have attempted so far.

First, I thought it would be easy to implement dataflow analysis for both mulDepth and plainMod using IntegerRangeAnalysis. So, I tried to follow the awesome blog post by @j2kun.

If I understand correctly, IntegerRangeAnalysis performs dataflow analysis by implementing transfer functions for each operation using the InferIntRangeInterface. During this process, I encountered two issues:

1. I need to implement two types of transfer functions for each operation (one for mulDepth and another for plainMod), but it seems InferIntRangeInterface allows for only one transfer function per operation (via the inferResultRanges method). Can this be resolved by implementing two interfaces that inherit from InferIntRangeInterface?

2. At the time this analysis is performed, the IR may include operations not only from the openfhe dialect but also from other dialects, such as arith dialect. Is there a way to initialize these operations easily? For instance, in the analysis for computing mulDepth, I think operations like arith.constant should all be initialized with a range of (0,0). I'm not sure if writing such initializations for all possible ops is feasible. Is there a better way?

I'm not very familiar with C++ and mlir, so these might be dumb questions. Any comments are welcome!

[j2kun]

I don't necessarily think you should use IntRangeAnalysis directly for this. If I were you I would write a new analysis that uses the same base framework (I'm mobile so I forget the name, something like AbstractForwardDataflowAnalysis, we have some examples already in HEIR I believe).

[Maokami]

Awesome, thank you for your comments! I will take a closer look.