[Mlir-commits] [mlir] mlir: add an operation to EmitC for function template instantiation (PR #100895)

[Gil Rapaport]

aniragil wrote:

> 1. Are we OK with a backwards breaking change to the dialect? @aniragil's suggestion would result in every emitc user of call_opaque having to change their code.

Sorry, should have been more clear: I'm not suggesting to modify `call_opaque` but to declare it deprecated as-is and remove it after a (long as needed) grace period for downstream users to use the new ops. A similar process is planned for other emitc ops following the `lvalue` discussions. It's difficult to make progress otherwise.

> 2. Unifying the operations might save some code inside emitc, but it will likely require some duplication of code in any user of emitc using template arguments. They'll probably have to pass around their list of template function arguments to both the instantiate call and the call_indirect op, versus doing it in a single place like it is now.

I'm not sure why that would be a problem, as the change means replacing each `call_opaque` with an `instantiate_template` immediately followed by a `call_indirect`, so any shared argument should be readily available.
Anyway, I'm actually less concerned about code duplication within EmitC (usually resolved using common functions) and more about functionality duplication within the dialect, especially complex ones. If unavoidable, we should make a (constant) effort to keep them as similar as possible to avoid confusing the users, but best is to avoid duplication where possible.

Another aspect is separating concerns: EmitC is used for various C variants, with templated-C++ being only one of. The `call_indirect` and `call_lib` ops would also serve C, non-templated C++, and hopefully other variants later on (e.g. OpenCL-C, CUDA). The current `call_opaque` therefore mixes `C++`-only template-instantiation aspects with more general function-call aspects, which separating them seems to resolve.

Another advantage of separating instantiation from the call is the ability to reuse the same template instance for multiple calls. This may be less useful for `decltype`-based instantiation but literal type instantiations may benefit from it.

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