Why not support MLIR instead of LLVM? #1913
Replies: 3 comments 1 reply
-
@chandlerc |
Beta Was this translation helpful? Give feedback.
-
No current plans -- my impression at least is that the overall design of MLIR is more focused on flexibility and progressive lowering. This is really impactful for a lot of high-level domain specific languages and problems (from numerical stuff to image manipulation pipelines, and obviously ML workloads). But typically, this kind of flexibility comes with a tradeoff of efficiency and large-scale. At least initially, we want to establish a baseline that deeply prioritizes large-scale and efficient representation of the program in the toolchain, and a more minimal and purpose-built set of data structures seems more effective for that. Of course, we may end up with a hybrid where some kernels are expressed in a higher level way and lower through MLIR or similar infrastructure, but the rest of the application software uses a lowering path designed for efficient scaling. But right now, or focus is on the baseline and getting enough information to decide on whether this experiment is worthwhile. |
Beta Was this translation helpful? Give feedback.
-
I gave a lightning talk at EuroLLVM earlier this year (slides) that also touches on this question. |
Beta Was this translation helpful? Give feedback.
-
Recently MLIR is getting well-known as a more flexible and high-performance compiler backend rather than using pure LLVM.
There are already some projects supporting MLIR even to compile C++ such as Polygeist, clangir, cil(deprecated?) since it can represent high-level abstraction like structured control flow, affine, vector and etc... (I understand C++ frontend cannot easily express them).
I'm wondering if there is any plan to use MLIR in Carbon language backend.
Beta Was this translation helpful? Give feedback.
All reactions