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

[Marius Brehler]

marbre wrote:

> > Sorry for not following up earlier. Isn't `call_lib` essentially the same as `call_opaque` with the lack of support for template arguments? In that case I think I would choose a different name instead of `call_lib` or even just keep the current name `call_opaque`. The disadvantage is that it is not as clear that the behavior will change as it would be with having a differently named op, but I favor this over introducing ops with not that clear names.
> 
> Then how about we extend `emitc.call` to accept string attrs, callable values and function pointers as callees in addition to symbols? Would that be enough to drop `emitc.call_opaque`?

I think we don't should go the way to extend options to much, which hasn't worked that well in the past. I think we should rather try to add new functionality with adding new ops. Therefore, I am in favor of adding an `emitc.call_indriect` similar to `func.call_indirect` and not add this to `emitc.call`.
My complains were more about not being happy about the naming of a _new_ `emitc.call_lib`. For me it would fine if we keep the name `emitc.call_opaque` but move (and extend!) the template args / instantiation to `emitc.instantiate_template`. I am aware that we get a `emitc.call_opaque` with changed functionality behind but we had a similar situation with renaming the former `emitc.call` op to `emitc.call_opaque` and introducing a entirely new `emitc.call` op. If we really look for a new name `emitc.opaque_call` could work but I think I am still in favor of keeping _an op named_ `emitc.call_opaque`. Hope this makes it clearer :)

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