- no more Concrete ciphertext/plaintext types: they are represented using standard MLIR types (int/tensor)
- Technically BConcrete was renamed to Concrete, and old Concrete was
removed
- TFHE -> Concrete now takes into account the conversion of tensor of
ciphertext into tensors of an additional dimension (LWE dim)
- Bufferization now works in Concrete
- Old Concrete optimization were moved to TFHE
- Concrete is now the dialect that lowers to CAPI calls
- TFHE -> Concrete now uses OpConversionPattern and is much cleaner in
terms of type conversion
- Disabled tests for batching, as there was something weird about it:
batchable operations implemented in Concrete but pass run in FHELinalg
this is a first commit to support operations on U64 by decomposing them
into smaller chunks (32 chunks of 2 bits). This commit introduce the
lowering pass that will be later populated to support other operations.
This adds a new option `--unroll-loops-with-sdfg-convertible-ops`,
which causes loops containing SDFG-convertible operations to be fully
unrolled upon the extraction of SDFG-operations using the
`--emit-sdfg-ops` switch. This avoids constant roundtrips between an
SDFG-capable accelerator and the host during execution of a loop.
The option is limited to `scf.for` loops with static bounds and a
static step size. Since full unrolling of loops with large bounds
results in a large number of operations, the option is disabled by
default.
This adds a new pass `ExtractSDGOps`, which scans a function for
operations that implement `SDFGConvertibleOpInterface`, replaces them
with SDFG processes and constructs an SDFG graph around the processes.
Initialization and teardown of the SDFG graph are embedded into the
function and take place at the beginning of the function and before
the function's terminator, respectively.
The pass can be invoked using concretecompiler by specifying the new
compilation option `--emit-sdfg-ops` or programmatically on a
`CompilerEngine` using the new compilation option `extractSDFGOps`.
This adds a new dialect called "SDFG" for data flow graphs. An SDFG
data flow graph is composed of a set of processes, connected through
data streams. Special streams allow for data to be injected into and
to be retrieved from the data flow graph.
The dialect is intended to be lowered to API calls that allow for
offloading of the graph on hardware accelerators.
The new option `--batch-concrete-ops` invokes the batching pass after
lowering to the Concrete dialect and after lowering linalg operations
with operations from the Concrete dialect to loops.
The new action `dump-concrete-with-loops` dumps the IR right before
batching.
- 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
Starting from Mac 11 (Big Sur), it appears we need to add -L
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem for the
sharedlib to link properly.i
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
Rebase to llvm-project at 3f81841474fe with a pending upstream patch
for arbitrary element types in linalg named operations.
Co-authored-by: Ayoub Benaissa <ayoub.benaissa@zama.ai>
This commit rebases the compiler onto commit f69328049e9e from
llvm-project.
Changes:
* Use of the one-shot bufferizer for improved memory management
* A new pass `OneShotBufferizeDPSWrapper` that converts functions
returning tensors to destination-passing-style as required by the
one-shot bufferizer
* A new pass `LinalgGenericOpWithTensorsToLoopsPass` that converts
`linalg.generic` operations with value semantics to loop nests
* Rebase onto a fork of llvm-project at f69328049e9e with local
modifications to enable bufferization of `linalg.generic` operations
with value semantics
* Workaround for the absence of type propagation after type conversion
via extra patterns in all dialect conversion passes
* Printer, parser and verifier definitions moved from inline
declarations in ODS to the respective source files as required by
upstream changes
* New tests for functions with a large number of inputs
* Increase the number of allowed task inputs as required by new tests
* Use upstream function `mlir_configure_python_dev_packages()` to
locate Python development files for compatibility with various CMake
versions
Co-authored-by: Quentin Bourgerie <quentin.bourgerie@zama.ai>
Co-authored-by: Ayoub Benaissa <ayoub.benaissa@zama.ai>
Co-authored-by: Antoniu Pop <antoniu.pop@zama.ai>
when dellocate is used to include dependencies in python wheels, the
runtime library will have an id that is prefixed with /DLC, and that path
doesn't exist. So when generated libraries won't be able to find it
during load time. To solve this, we change the dep in the generated
library to be relative to the rpath which should be set correctly during
linking. This shouldn't have an impact when /DLC/concrete/.dylibs/* isn't
a dependecy in the first place (when not using python).
also set rpath when linking to RT lib
