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
Quick fix due to ordering of includes, had to add #include
<mlir/Transforms/DialectConversion.h> to include/concretelang/Conversion/Utils/GenericOpTypeConversionPattern.h
Resolves#288
example
before:
Failed to lower to LLVM dialect
after:
Failed to lower to LLVM dialect
test.mlir:3:10: error: unexpected error: 'linalg.copy' op expected indexing_map #1 to have 2 dim(s) to match the number of loops
%0 = tensor.extract_slice %arg0[0, 0] [3, 1] [1, 1] : tensor<3x2x!HLFHE.eint<3>> to tensor<3x!HLFHE.eint<3>>
^
By default, `mlir::SourceMgrDiagnosticVerifierHandler` used by
`CompilerEngine::compile()` prints parse errors to
`llvm::errs()`. This makes it impossible for a caller of
`CompilerEngine::compile()` to process parse errors or to suppress the
emission of error messages to the standard error stream altogether.
This change captures parse errors in a string via a string-backed
output stream and forwards the error message in the `llvm::Error`
instance of the return value.
This commit contains several incremental improvements towards a clear
interface for lambdas:
- Unification of static and JIT compilation by using the static
compilation path of `CompilerEngine` within a new subclass
`JitCompilerEngine`.
- Clear ownership for compilation artefacts through
`CompilationContext`, making it impossible to destroy objects used
directly or indirectly before destruction of their users.
- Clear interface for lambdas generated by the compiler through
`JitCompilerEngine::Lambda` with a templated call operator,
encapsulating otherwise manual orchestration of `CompilerEngine`,
`JITLambda`, and `CompilerEngine::Argument`.
- Improved error handling through `llvm::Expected<T>` and proper
error checking following the conventions for `llvm::Expected<T>`
and `llvm::Error`.
Co-authored-by: youben11 <ayoub.benaissa@zama.ai>
LLVM errors should be handled/consumed. Creating a new one and leaving
the previous one alive will crash the compiler. Whenever we don't want a
crash (e.g. logging the error is enough), but still wanna continue the
execution, we can just consume it.
This replaces the default FHE circuit constrains (maximum encrypted
integer width of 7 bits and a Minimal Arithmetic Noise Padding of 10
with the results of the `MaxMANP` pass, which determines these values
automatically from the input program.
Since the maximum encrypted integer width and the maximum value for
the Minimal Arithmetic Noise Padding can only be derived from HLFHE
operations, the circuit constraints are determined automatically by
`zamacompiler` only if the option `--entry-dialect=hlfhe` was
specified.
For lower-level dialects, `zamacompiler` has been provided with the
options `--assume-max-eint-precision=...` and `--assume-max-manp=...`
that allow a user to specify the values for the maximum required
precision and maximum values for the Minimal Arithmetic Noise Padding.
