converting types of the original op seems to have an impact on other
operations using the result type, which should consider checking the
different cases (whether the type has been converted yet, or not).
However, creating a new op don't have this issue
- unify CPU and GPU bootstrapping operations
- remove operations to build GLWE from table: this is now done in
wrapper functions
- remove GPU memory management operations: done in wrappers now, but we
will have to think about how to deal with it later in MLIR
This patch adds support for scalar results to the client/server
protocol and tests. In addition to `TensorData`, a new type
`ScalarData` is added. Previous representations of scalar values using
one-dimensional `TensorData` instances have been replaced with proper
instantiations of `ScalarData`.
The generic use of `TensorData` for scalar and tensor values has been
replaced with uses of a new variant `ScalarOrTensorData`, which can
either hold an instance of `TensorData` or `ScalarData`.
This adds a new function `getLambdaArgumentTypeAsString(const
LambdaArgument&)` returning the name of a lambda argument type as a
string, e.g., `"uint8_t"` for an `IntLambdaArgument<uint8_t>` or
`"tensor<uint8_t>"` for a
`TensorLambdaArgument<IntLambdaArgument<uint8_t>>`.
Note that, due to the static inheritance scheme for Lambda Arguments
and explicit instantiation, this is only implemented for the common
backing integer types `uint8_t`, `int8_t`, `uint16_t`, `int16_t`,
`uint32_t`, `int32_t`, `uint64_t`, and `int64_t`.
Returning tensors with elements whose width is not equal to 64 results
in garbled data. This commit extends the `TensorData` class used to
represent tensors in JIT compilation with support for signed /
unsigned elements of 8/16/32 and 64 bits, such that all clear text
tensors with up to 64 bits can be represented accurately.
For now what it works are only levelled ops with user parameters. (take a look to the tests)
Done:
- Add parameters to the fhe parameters to support CRT-based large integers
- Add command line options and tests options to allows the user to give those new parameters
- Update the dialects and pipeline to handle new fhe parameters for CRT-based large integers
- Update the client parameters and the client library to handle the CRT-based large integers
Todo:
- Plug the optimizer to compute the CRT-based large interger parameters
- Plug the pbs for the CRT-based large integer
