[ThroughMLIR] variadic functions (and printf) support

[felixdaas]

Currently the MLIR core func dialect func.func operation doesn't support variadic functions. Because of this the indirect lowering fails if variadic functions like printf are used in the case that variadic params are passed with

loc("test.c":44:3): error: 'func.call' op incorrect number of operands for callee

If printf or other variadic functions are used without any variadic params (e.g. to just print something like "Hello World!") the compilation actually goes through but faulty llvm IR is created and when trying to execute the programm a Segmentation fault occurs.

In contrast the llvm.func operation does support variadic functions, but I think there are two problems with using this operation in the mlir core stage of the lowering.

1. As mentioned in Lowering through MLIR standard dialects: class, struct, arrays and other issues #1219 by @keryell "having low-level LLVM dialect in the middle of MLIR higher-level standard dialect, making more difficult to target other back-ends such as SPIR-V or various hardware accelerators not relying on the LLVM back-end directly but on their own dialects. This would require raising some LLVM dialect constructs back to something higher-level", I'm not that familiar with those targets but as far as I understand it most of them don't use/support variadic functions anyways, so that might not be a big issue. It's still not ideal.
2. The other (maybe more important) issue is that the core dialects work with memref types and the llvm dialect operations don't. There is also as far as I know no builtin way to cast memref values to !llvm.ptr values. I'm not super familiar with polygeist but I think this is solved there with exactly an operation like this (a custom polygeist memref to !llvm.ptr cast).

So an option would be to create a similar cir operation like this, that is still alive in the core dialect representation, and is lowered in the mlir core to mlir llvm ir dialect lowering (to basically just forward the data ptr !llvm.ptr value). The downside would be that we would have a cir operation that doesn't really fit with all the other cir operations (as it wouldn't be used with the other cir ops, but inserted in the cir to mlir core lowering at the necessary locations) and only has meaning in the indirect lowering.

The upside would be that, we could already support variadic functions with the TroughMLIR lowering without changes to upstream mlir. Still the better option is probably to wait until upstream support is added to the func dialect. There has also been a question about this and indirect function support in the LLVM forum in October 2024 and since then support for indirect calls has been added.

[bcardosolopes]

The upside would be that, we could already support variadic functions with the TroughMLIR lowering without changes to upstream mlir. Still the better option is probably to wait until upstream support is added to the func dialect

Seems like the best option unless you are blocked by this :)

[keryell]

As a work-around, if you program in C++ you can replace variadic functions with variadic templates, like std::print for example.
If you want to try the cast operation, you can always use an unrealized_conversion_cast operation for this by making it conditionally legal in your dialects and transformations.