[Mlir-commits] [mlir] [mlir][EmitC] Refactor MLIR Translate To Cpp (PR #84973)

[Marius Brehler]

marbre wrote:

Thank you for your work @weizchen. It is undeniable that the emitter can be improved. However, after a first glance, I think there are both conceptual and technical issues. I'm afraid that this will definitely require some discussions and iterations before it could potentially be merged.

Let me provide more context and some background information. When we proposed the emitter for upstream inclusion, the were concerns and push back mainly due to the API of the emitter. At that time, the consensus was to keep the surface of the emitter as small as possible. This also made it necessary for us to fork the emitter for our use case in IREE. However, we have now evolved the EmitC dialect to a point where we no longer need a forked emitter, as we can achieve what we need through conversions. Hence, @simon-camp recently removed the forked emitter from IREE with PR [#16357 at IREE](https://github.com/openxla/iree/pull/16357).

The intention is to remove all non-EmitC operations from the emitter. Support for operations of the SCF dialect were removed with PR #68206 and we recently accepted PR #83798 that removed support for the Arith dialect. With PR #79612, I added a func, call and return operation. The only reason for us not yet removing support for the Func dialects ops from emitter is to not break downstream users as EmitC's operations don't support multiple return values. Instead of extending the emitter, we aim to further develop the dialect in a way that everything can be accomplished through conversions. To me, it seems that the proposed changes do not align with this intention.
For completeness, this also seems related to the discussion [[RFC] The Natural Intersection of MLIR and C](https://discourse.llvm.org/t/rfc-the-natural-intersection-of-mlir-and-c/68708/2).

Furthermore, there are some mechanical issues. For example the implementation in `CppTranslationUtils` heavily relies on EmitC ops and further pulls in the CF dialect. Hence, it not just provides shared functions as most functions are not *dialect independent*.

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