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

[llvmlistbot at llvm.org]

Menooker wrote:

Thanks for @rengolin for the view!

> Can we add this to the existing primitives?

What I would like to do is to add the functionality of printing values in MLIR. It would be very helpful when debugging and writing tests, since users can print arithmetic values any where in the MLIR code. Also developers can use filecheck on the outputs by printf. 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.

> Do we need a whole libc dialect? Perhaps c++ too?

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.

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.

>  adding a whole dialect just for this opens a dialect discussion that is far wider than this one function.

I totally understand that it is overkill to add a dialect for a single Op. My original proposal is to add an printf op for CPU. I have found an `gpu.printf`. There is no reason not having a CPU one, since it is easier to implement and equally useful. However, there is no such `cpu` dialect to hold the `printf` op, and there seems nowhere to place such op. That's why I added this dialect.

After more searching, I found that in `vector` dialect, there is `vector.print` which can print scalar values and etc. And this op lowers to `printF32` or other functions in `CRunnerUtils` on CPU. So there may be 3 ways for me to introduce this printf for CPU:

1. Add to vector dialect, as `vector.printf`. However, it seems a bit strange to put such op in vector dialect.
2. Instead of introducing `libc` dialect, introduce a new `print` dialect. Besides `print.printf`, we can introduce `print.printMemref` (`print.printTensor` also?)
3. Introduce `libc` dialect. Add more Ops into it, like `abort` and `assert` discussed above. Or we may call it `debug` dialect, for debugging purpose ops?

> Some nits on the code. Also, your tests are not enough. You need to cover the functionality you add, including the error messages that you expect to get on a negative test.

Thanks for pointing out! I am an MLIR beginner here. Will improve them! :)

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