[Mlir-commits] [mlir] [mlir] [Dialect] Add LibC dialect and printf op for CPU (PR #92369)

[Renato Golin]

rengolin wrote:

> The printing primitives you mentioned does not support formatting and need to declare the functions before using, which is not easy to use in IR.

Indeed, we had the same problem in the past, but decided to [print tensors/memrefs as vectors](https://github.com/plaidml/tpp-mlir/blob/08caaf675eed621f6ae06c83bc7bd06441550bf8/lib/TPP/Runner/MLIRBench.cpp#L318).

> Other interesting features in libc I know will be the ability of `assert` and `abort`. We may introduce them as Ops in `LibC` dialect too. `assert` is a C-macro, but I think it is a good-to-have in MLIR, for example, to help debug the program in "-O0" mode, with printing the `Source Location` . Based on it, some other features can be implemened. Memref dialect can use `libc.assert` to make sure the user-passed memref in func args have the claimed rank and dimensions at the entry. Another useful feature based on `libc.assert` is the boundary checking on memory accesses on memref. I am not sure if these features are already in MLIR or not.

We have added "runner" functionality in local dialects ([check](https://github.com/plaidml/tpp-mlir/blob/main/include/TPP/Dialect/Check/CheckOps.td), [perf](https://github.com/plaidml/tpp-mlir/blob/main/include/TPP/Dialect/Perf/PerfTypes.td)), but never quite found the place to put them. 

I think there's a common trend between all these little functions and it's not `libc`. I'd call it `runner` or `runtime` or just `run` and de-compose the `gpu.printf` into `gpu.get_tensor` + `run.printf`, for example. I'd also add the benchmark loops, checking of values, etc.

> C++ has complex ABI issues and many of its useful features are based on templates. I don't think we need `libcpp` dialect for now.

Right, I was using it to show how quickly this can escalate if we chose a tangent path. :)

I do like the idea of improving the ability to print stuff in MLIR, but just a printf wrapper is too much for a new dialect.

Right now, you can already lower your formatted printf into LLVM dialect call, so this should be enough for _just_ basic printf. On the rest of the _"runtime dialect"_, I think an RFC is in order to make sure we converge to a common design.

I'd love to find a home for our `check` and `perf` dialects.

https://github.com/llvm/llvm-project/pull/92369