Rebase to llvm-project at 3f81841474fe with a pending upstream patch
for arbitrary element types in linalg named operations.
Co-authored-by: Ayoub Benaissa <ayoub.benaissa@zama.ai>
This commit is introduced because python bindings for `tensor.from_elements` are not generated automatically. Previously, we overcame this with string manipulation, but with the latest version of the compiler, it became a problem. This commit should be reverted eventually. See https://discourse.llvm.org/t/cannot-create-tensor-from-elements-operation-from-python-bindings/4768 for the discussion in LLVM forums.
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>
Some virtual functions in `LambdaSupport.h` are meant to be purely
virtual, but lack a `= 0` in their signature. In debug builds, this
causes the linker to look for a default implementation, resulting in a
linker error.
This patch marks the virtual functions as purely virtual, resolving
the linker issues in debug builds.
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
