Cross-pasting from this thread that may also be relevant to you: Linagl VS Affine - #9 by nicolasvasilache
Here is a minimal test that we have to lower linalg to library calls.
Note the very primitive name mangling that produces e.g.:
func private @linalg_matmul_viewsxsxf32_viewsxsxf32_viewsxsxf32(
memref<?x?xf32, {{.*}}>, memref<?x?xf32, {{.*}}>, memref<?x?xf32, {{.*}}>)
attributes {llvm.emit_c_interface}
This can then lower to LLVM and be connected to a .so that implements the functionality you want in C++. It used to be a proper end-to-end integration test connected to the runner but we have scaled back from that since the orthogonal steps needed for the runner and linking are captured in this test.
Basically, connecting the 2 pieces above and having a simple stub for matmul written in C++ of dispatching to another library is easy; if you have it difficult I can revive some old code.
Here is the basic pass.
I would love some effort here, the lack of prioritization on this front has been unfortunate.
Here is a related older thread: Lowering optional attributes in Linalg StructuredOps to Standard dialect.
A lot of things are missing to get this polished and to a point where it can scale and we can properly mix codegen + library calls. They are all quite unambiguous but potentially a lot of work depending on the degree of usability and pluggability one is interested in.
If this sounds interesting, I am happy to jolt down a few starter tasks and push this forward.