mirror of
https://github.com/zama-ai/concrete.git
synced 2026-02-08 11:35:02 -05:00
c8c969773e
This commit rebases the compiler onto commit 465ee9bfb26d from
llvm-project with locally maintained patches on top, i.e.:
* 5d8669d669ee: Fix the element alignment (size) for memrefCopy
* 4239163ea337: fix: Do not fold the memref.subview if the offset are
!= 0 and strides != 1
* 72c5decfcc21: remove github stuff from llvm
* 8d0ce8f9eca1: Support arbitrary element types in named operations
via attributes
* 94f64805c38c: Copy attributes of scf.for on bufferization and make
it an allocation hoisting barrier
Main upstream changes from llvm-project that required modification of
concretecompiler:
* Switch to C++17
* Various changes in the interfaces for linalg named operations
* Transition from `llvm::Optional` to `std::optional`
* Use of enums instead of string values for iterator types in linalg
* Changed default naming convention of getter methods in
ODS-generated operation classes from `some_value()` to
`getSomeValue()`
* Renaming of Arithmetic dialect to Arith
* Refactoring of side effect interfaces (i.e., renaming from
`NoSideEffect` to `Pure`)
* Re-design of the data flow analysis framework
* Refactoring of build targets for Python bindings
* Refactoring of array attributes with integer values
* Renaming of `linalg.init_tensor` to `tensor.empty`
* Emission of `linalg.map` operations in bufferization of the Tensor
dialect requiring another linalg conversion pass and registration
of the bufferization op interfaces for linalg operations
* Refactoring of the one-shot bufferizer
* Necessity to run the expand-strided-metadata, affine-to-std and
finalize-memref-to-llvm passes before converson to the LLVM
dialect
* Renaming of `BlockAndValueMapping` to `IRMapping`
* Changes in the build function of `LLVM::CallOp`
* Refactoring of the construction of `llvm::ArrayRef` and
`llvm::MutableArrayRef` (direct invocation of constructor instead
of builder functions for some cases)
* New naming conventions for generated SSA values requiring rewrite
of some check tests
* Refactoring of `mlir::LLVM::lookupOrCreateMallocFn()`
* Interface changes in generated type parsers
* New dependencies for to mlir_float16_utils and
MLIRSparseTensorRuntime for the runtime
* Overhaul of MLIR-c deleting `mlir-c/Registration.h`
* Deletion of library MLIRLinalgToSPIRV
* Deletion of library MLIRLinalgAnalysis
* Deletion of library MLIRMemRefUtils
* Deletion of library MLIRQuantTransforms
* Deletion of library MLIRVectorToROCDL
Concrete
The concrete project is a set of crates that implements Zama's variant of
TFHE and make it easy to use. In a nutshell,
fully homomorphic encryption (FHE), allows
you to perform computations over encrypted data, allowing you to implement Zero Trust services.
Concrete is based on the Learning With Errors (LWE) and the Ring Learning With Errors (RLWE) problems, which are well studied cryptographic hardness assumptions believed to be secure even against quantum computers.
Project layout
The concrete project is a set of several modules which are high-level frontends, compilers, backends and side tools.
- The
frontendsdirectory contains apythonfrontend. - The
compilersdirectory contains theconcrete-compilerandconcrete-optimizermodules. Theconcrete-compileris a compiler that synthetize a FHE computation dag expressed as a MLIR dialect, compile to a set of artifacts, and provide tools to manipulate those artifacts at runtime. Theconcrete-optimizeris a specific module used by the compiler to find the best, secure and accurate set of crypto parameters for a given dag. - The
backendsdirectory contains implementations of cryptographic primitives on different computation unit, used by theconcrete-compilerruntime. Theconcrete-cpumodule provides CPU implementation, whileconcrete-cudamodule provides GPU implementation using the CUDA platform. - The
toolsdirectory contains side tools used by the rest of the project.