Commit Graph

24 Commits

Author SHA1 Message Date
youben11
9de1776753 fix: fix imports 2022-03-28 13:42:18 +01:00
Quentin Bourgerie
1b984f5119 cleanup(python): Cleanup python bindings after refactoring of CompilerEngine 2022-03-24 11:00:36 +01:00
Quentin Bourgerie
8867d313ee feat(python): Expose Jit and Library compiler support 2022-03-24 11:00:36 +01:00
youben11
940cb96be4 chore: rename dialects
HLFHE to FHE
MidLFHE to TFHE
LowLFHE to Concrete
2021-12-29 15:13:34 +01:00
youben11
47ef595a2a chore: use namespace concrete for the py package
Compiler tools such as CompilerEngine would now be imported from
concrete.compiler
Dialects would now be imported from concrete.lang.dialects
And anything related to concretelang can be imported directly from
concrete.lang
2021-12-29 15:13:34 +01:00
youben11
e73291abdc chore: rename compiler to concrete-compiler
zamalang => concretelang
zamacompiler => concretecompiler
2021-12-29 15:13:34 +01:00
youben11
60b2cfd9b7 feat: support more dtype for scalars/tensors
dtype supported now: uint8, uint16, uint32, uint64
2021-12-13 17:40:28 +01:00
youben11
550318f67e feat: support different numpy object types as input
- Scalar types: int, np.uint8 (to extend with other types later), and np.ndarray with shape == ()
- Tensor types: np.ndarray
2021-12-13 17:40:28 +01:00
Mayeul@Zama
dad4390518 feat(compiler): add a key cache 2021-12-07 12:11:56 +01:00
rudy
975ee86a5e feat(compiler): add --compile option
Resolves #196
2021-11-30 17:42:28 +01:00
rudy
97389a3b06 Move HLFHE.dot_eint_int to HLFHELinalg.
Resolves #183
2021-11-09 11:39:08 +01:00
youben11
59e859177c refactor: replace ExecutionArg by TensorLambdaArg
This add support for tensor inputs from the python bindings
2021-11-08 11:55:02 +01:00
youben11
b501e3d6c0 feat(python): support functions returning tensors 2021-11-08 11:55:02 +01:00
Andi Drebes
0cb5007c3c enhance(compiler): Python bindings: Forward llvm::Expected error messages in exceptions
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.
2021-11-02 16:34:42 +01:00
youben11
03c1588db4 chore: update to LLVM 8b7cc93e
major changes:
- https://llvm.discourse.group/t/psa-removed-arithmetic-ops-from-standard/4455
- use add_mlir_public_c_api_library helper to correctly add a CAPI library
2021-10-29 16:08:41 +01:00
Andi Drebes
1187cfbd62 refactor(compiler): Refactor CompilerEngine and related classes
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>
2021-10-29 13:44:34 +02:00
youben11
01757fa6d5 fix: forward errors instead of creating new ones
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.
2021-10-12 11:50:15 +01:00
youben11
450925b7bf chore(python test): clean test case by adding ids 2021-10-07 14:38:50 +01:00
youben11
967fda07a0 feat(execution): run on both int and tensor args 2021-09-10 10:00:04 +01:00
youben11
746d991af6 refactor: ins forward decl w generic ty @pass-init
Insert forward declarations with generic types at pass initialization.
More docs for all the pass for lowering LUT
2021-09-09 20:35:28 +02:00
youben11
272a725e9a feat(lower_LUT): add precision attribute to encode LUT at runtime 2021-09-09 20:35:28 +02:00
youben11
c4dd639ea7 tests(LUT): use relative error 2021-09-09 20:35:28 +02:00
youben11
855dabc91e tests: apply_univ complete lowering and execution 2021-09-09 20:35:28 +02:00
youben11
f948db1228 feat(python): CompilerEngine to compile and run 2021-08-18 17:38:46 +02:00