Add a rewrite pattern that transforms an instance of
`HLFHELinalg.zero` into an instance of `linalg.generate` with an
appropriate region yielding a zero value.
Example:
%out = "HLFHELinalg.zero"() : () -> tensor<MxNx!HLFHE.eint<p>>
becomes:
%0 = tensor.generate {
^bb0(%arg2: index, %arg3: index):
%zero = "HLFHE.zero"() : () -> !HLFHE.eint<p>
tensor.yield %zero : !HLFHE.eint<p>
} : tensor<MxNx!HLFHE.eint<p>>
Add a new operation `HLFHELinalg.zero`, broadcasting an encrypted,
zero-valued integer into a tensor of encrypted integers with static
shape.
Example creating a one-dimensional tensor with five elements all
initialized to an encrypted zero:
%tensor = "HLFHELinalg.zero"() : () -> tensor<5x!HLFHE.eint<4>>
Operations with regions currently need explicit patterns for type
conversion throughout lowering. This change adds the required patterns
for `tensor.generate` to the lowering passes, such that the operation
can be used starting from the lowering from HLFHE to MidLFHE.
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>>
^
Replace `LinalgGenericTypeConverterPattern`, specialized for
`linalg.generic` with a generic type converter pattern
`RegionOpTypeConverterPattern` that can be instantiated for any
operation that has one or more regions.
Further enhancements:
- Supports multiple regions
- Uses more idiomatic instantiations of `llvm::for_each` instead of
manual iterations using for loops
Try to find the runtime library automatically (should only work on
proper installation of the package), and fail silently by not passing
any RT lib. The RT lib can also be specified manually. The RT lib will
be used as a shared library by the JIT compiler.
Add a new method `JITLambda::Arguments::getResultWidth` returning the
width of a scalar result or the element type of a tensor result at a
given position.
Currently, `JITLambda::Arguments` assumes result tensors are always
composed of `uint64_t` elements. This change adds support for
arbitrary scalar element types.
All results in code compiled by zamacompiler are passed as return
values, which means that all tensors passed as function arguments are
constant inputs that are never written.
This patch changes the arguments used as data pointers for input
tensors in `JITLambda::Arguments::setArg()` from `void*` to `const
void*` to emphasize their use as inputs and to allow for constant
arrays to be passed as function inputs.
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.
The code in `lib/CAPI/Support/CompilerEngine.cpp` invokes several
functions returning an `llvm::Expected<T>`. When those fail, the error
message retrieved from the error object the `llvm::Expected<T>`
instance is written to the standard error stream via
`mlir::zamalang::log_error()` and an exception with a more generic
error message is thrown.
This causes errors to show up on the standard error stream in tests
generating errors on purpose and checking them, e.g.:
```
tests/python/test_compiler_engine.py::test_compile_invalid[not
@main] Compilation failed: cannot find the function for generate
client parameters PASSED
```
This patch forwards the error message from an `llvm::Expected<T>`
instance in a runtime exception rather than writing it to the standard
error stream. Since exceptions are properly caught by the tests, no
errors show up during testing.
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>
