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
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`.
This adds a new optional boolean parameter
`use_default_fhe_constraints` to the YAML description of tests that
causes the test backend to use the default FHE constraints if set to
true. This is necessary for clear text tests, since automatic
determination of FHE parameters by the `CompilerEngine` fails for
programs not using encrypted integers and causes the program to abort.
This adds a new variable `BUILD_TYPE` to the Makefile, controlling
whether the build should be a debug or a release build (values `Debug`
and `Release`, respectively). The default mode is `Release`. Depending
on the build type, the build directory is set to `build-Debug` or
`build-Release`. This enables debug and release builds to co-exist and
to switch easily between the two.
The code in `loadEndToEndDesc` attempts to load the contents of a YAML
file without ensuring that the stream from which the file is read was
set up correctly. As a result, streams in a bad state, e.g., if the
file to be opened does not exist, simply result in an empty string for
the file contents. The test driver cannot distinguish this result from
a valid YAML file that is simply empty.
This patch causes `loadEndToEndDesc` to abort execution whenever a
file input stream could not be set up correctly.
Returning tensors with elements whose width is not equal to 64 results
in garbled data. This commit extends the `TensorData` class used to
represent tensors in JIT compilation with support for signed /
unsigned elements of 8/16/32 and 64 bits, such that all clear text
tensors with up to 64 bits can be represented accurately.
The bufferization of the BConcrete dialect emits calls to Concrete
wrapper functions and casts all memrefs to ranked memrefs with dynamic
strides and an implicit identity layout map. The implicit identity map
does not allow for casts of memrefs with non-zero offsets, e.g.,
resulting from folding of memrefs related to intermediate results
passed as operands to the operation implemented by a wrapper.
Casting to memrefs symbolic offsets in the layout map (e.g.,
`[d0, d1, ...](s0, s1, ...) -> (d0 + s0, d1 + s1, ...)`) allows
for more flexibility, in particular this adds support for memrefs
with non-zero, constant offsets returned by operations generating
intermediate results.