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 Compiler
The Concrete Compiler is a set of tools that allows the compilation and from an high-level and crypto free representation of an arithmetic circuit of operations on encrypted integers. This compiler is based on the MLIR project it use the framework, the standard dialects exposed by MLIR and define new fhe specific dialects and passes to lower the high-level fhe dialects to standard MLIR dialects.
Getting started
The source of the project is located in the compiler directory.
cd compiler
Prerequisite: Building HPX and enable dataflow parallelism (optional)
In order to implement the dataflow parallelism and the distribution of the computation we use the HPX Standard Library. You can else use your own HPX installation by set the HPX_INSTALL_DIR environment variable or you can install HPX on the default path of our build system thanks the following command:
make install-hpx-from-source
This may fail on some systems when dependencies are missing. Some recent packages required are Cmake, HWLOC and BOOST. For full details see HPX Quickstart guide.
Once you have a proper installation of HPX to enable the dataflow parallelism set the DATAFLOW_EXECUTION_ENABLED=ON.
Prerequisite: Fetch git submodules
This project rely on llvm-project and concrete-optimizer as git submodules so you need to initialize and update the git submodules.
git submodule init
git submodule update
Prerequisite: python packages
Install MLIR python requirements in your dev python environment:
# From repo root
pip install -r ./llvm-project/mlir/python/requirements.txt
# From compiler dir
pip install -r ../llvm-project/mlir/python/requirements.txt
Build from source
We use cmake as the main build system but in order to initialize the build system and define straightforward target for the main artifacts of the project. You can initialize and build all the main artifacts thanks the following command:
make all
or in several steps:
Generate the compiler build system, in a build-* directory
make build-initialized
Build the compiler
make concretecompiler
Run the compiler
./build-Release/bin/concretecompiler
Installation from source
You can install libs, bins, and include files into a specific directory by running:
make INSTALL_PREFIX=/your/directory install
You will then find lib, bin, and include under /your/directory/concretecompiler.
Tests
You can build all the tests with the following command:
make build-tests
and run them with:
make run-tests
Benchmarks
You can build all the benchmarks with the following command:
make build-benchmarks
and run them with:
make run-benchmarks
Build releases
Build tarball
You can create a tarball containing libs, bins, and include files for the tools of the compiler, by following previous steps of installation from source, then creating a tar archive from the installation directory.
Build the Python Package
Currently supported platforms:
- Linux x86_64 for python 3.7, 3.8, 3.9, and 3.10
pybind11 is required to build the python package, you can install it in your current environment with:
$ pip install pybind11
To specify which python executable to target you can specify the Python3_EXECUTABLE environment variable.
Build wheels in your environment
Building the wheels is actually simple.
$ pip wheel --no-deps -w ../wheels .
Depending on the platform you are using (specially Linux), you might need to use auditwheel to specify the platform this wheel is targeting. For example, in our build of the package for Linux x86_64 and GLIBC 2.24, we also run:
$ auditwheel repair ../wheels/*.whl --plat manylinux_2_24_x86_64 -w ../wheels