The rust bindings are intented to access both LLVM/MLIR CAPI as well as
the concrete-compiler one. This initial commit provide the API for
LLVM/MLIR only. Tests should be used as an example to how to generate a
valid DAG of operations in MLIR.
converting types of the original op seems to have an impact on other
operations using the result type, which should consider checking the
different cases (whether the type has been converted yet, or not).
However, creating a new op don't have this issue
- unify CPU and GPU bootstrapping operations
- remove operations to build GLWE from table: this is now done in
wrapper functions
- remove GPU memory management operations: done in wrappers now, but we
will have to think about how to deal with it later in MLIR
This includes several fixes and add some functionalities:
* EC2 instance type can be selected when workflow is triggered manually
* benchmarks will be run on each push on main branch
* docker is not used any more due to building issues
* 10 repetitions are made during the benchmarks then results are aggregated
* more tags are used to identify benchmarks configuration
This updates the llvm-project repository to a version containing a
patch that avoids excessive stack growth for programs whose IR
contains `memref.copy` operations in the bodies of loops with a high
trip count (e.g., `mnist_28_mlir_7b`).
This fixes Issue #669.
When building the ServerLib before any other concretelang target that
depends on `mlir-headers`, compilation fails due to missing include
files generated by tablegen, e.g., `llvm/IR/Attributes.inc`.
This adds a dependency from ServerLib to `mlir-headers`, which forces
the generation of the missing header files.
This adds four new targets `opt`, `mlir-cpu-runner`, `mlir-opt`, and
`mlir-translate` to the toplevel Makefile of the compiler to
conveniently build the corresponding LLVM / MLIR utilities (e.g., for
debugging purposes).
The target `run-mlbench` indirectly depends on the contents of
`tests.ml/bench.zip` which are extracted by `generate-mlbench`. If
`generate-mlbench` has not been built pefore, `run-mlbench`
fails. This adds a the missing dependency from `run-mlbench` to
`generate-mlbench`.
This moves all tests from
`tests/end_to_end_tests/end_to_end_jit_clear_tensor.cc` to the test
specification in YAML format in
`tests/end_to_end_fixture/end_to_end_clear_tensor.yaml`. Parametric
tests and tests invoking lambdas in loops have been fully unrolled.
This patch adds support for scalar results to the client/server
protocol and tests. In addition to `TensorData`, a new type
`ScalarData` is added. Previous representations of scalar values using
one-dimensional `TensorData` instances have been replaced with proper
instantiations of `ScalarData`.
The generic use of `TensorData` for scalar and tensor values has been
replaced with uses of a new variant `ScalarOrTensorData`, which can
either hold an instance of `TensorData` or `ScalarData`.
This adds a new function `getLambdaArgumentTypeAsString(const
LambdaArgument&)` returning the name of a lambda argument type as a
string, e.g., `"uint8_t"` for an `IntLambdaArgument<uint8_t>` or
`"tensor<uint8_t>"` for a
`TensorLambdaArgument<IntLambdaArgument<uint8_t>>`.
Note that, due to the static inheritance scheme for Lambda Arguments
and explicit instantiation, this is only implemented for the common
backing integer types `uint8_t`, `int8_t`, `uint16_t`, `int16_t`,
`uint32_t`, `int32_t`, `uint64_t`, and `int64_t`.
