The basic idea is a good one, and the underlying tech (MLIR) is the right choice as it's an existing part of the LLVM infrastructure.<p>The question, however, is why this particular IR implementation, given there are a number of ongoing efforts to do general C/C++ MLIR implementations. The urgency for upstreaming this change is a little weird, as i'd expect the community to take real time to investigate and think through the IR choices.<p>I attended an LLVM conference earlier in the year, and they are a smart bunch with <i>really</i> deep understanding of this stuff, so I expect they will have opinions as to whether this is the right implementation, and whether this is the right time to adopt it.<p>On a side note, one of the dangers of MLIR as far as I can see is an unfortunate side effect that optimisations performed on the language IR will not be available to other languages which use either LLVM IR or their or MLIR variant. This will either mean there are lost optimisation opportunities, or duplicate effort to port passes to other MLIR variants. That'll be a shame.
I read the projects web page and github page, but nowhere did I see any detailing of the "why". Why do we need another IR for LLVM?<p>I am working on the frontend for a toy lang, and was planning to transpile to LLVM IR. This is of interest to me. But its frustrating how opaque the dev docs for such projects are.
I read up to the may_explode example. You can already analyse this in clang. I have no idea what the actual point of any of this is since it claims something that is in reality already being done. Also the syntax is much harder to read than the current ir
<a href="https://discourse.llvm.org/t/rfc-an-mlir-based-clang-ir-cir/63319" rel="nofollow">https://discourse.llvm.org/t/rfc-an-mlir-based-clang-ir-cir/...</a> :<p>> Our current (and initial) goal is to provide a framework for improved diagnostics for modern C++, meaning better support for coroutines and checks for idiomatic uses of known C++ libraries.<p>...<p>> In general, Clang’s AST is not an appropriate representation for dataflow analysis and reasoning about control flow. On the other hand, LLVM IR is too low level — it exists at a point in which we have already lost vital language information (e.g. scope information, loop forms and type hierarchies are invisible at the LLVM level), forcing a pass writer to attempt reconstruction of the original semantics. This leads to inaccurate results and inefficient analysis - not to mention the Sisyphean maintenance work given how fast LLVM changes. Clang’s CFG is supposed to bridge this gap but isn’t ideal either: a parallel lowering path for dataflow diagnostics that (a) is discarded after analysis, (b) has lots of known problems (checkout Kristóf Uman’s great survey 28 regarding “dataflowness”) and (c) has testing coverage for CFG pieces not quite up to LLVM’s standards.<p>> We also have the prominent recent success stories of Swift’s SIL and Rust’s HIR and MIR. These two projects have leveraged high level IRs to improve their performance and safety. We believe CIR could provide the same improvements for C++.