An LLVM backend leverages LLVM’s infrastructure of instruction selector, register allocator, etc.
But LLVM’s machine-level code is pretty complicated and the community is not as active as the MLIR one.
I’m interesting in what the MLIR community’s thoughts on writing a hardware target as an MLIR dialect.
I’m not sure about this, there are lots of traffics on the codegen / targets parts of LLVM if you look at the commit history.
Personally I think performing codegen directly from high-level MLIR dialects can avoid some hassles of translating to LLVM IR first and I agree that Machine IR is not the most pleasant format to work with (though not really complicated once you get used to). However, this also forgoes the benefits brought by low-level optimizations performed on LLVM IR, unless we replicate the exact same set of optimizations on, says LLVM IR dialect.
This reminds me the keynote of LLVM Dev Meeting 2022 [video] where Nicolai talked about unifying MLIR and LLVM infrastructure.
I can foresee a future where not only does individual targets have their own dialect, different core codegen infrastructures (e.g. instruction selector) also have more freedom on picking their own level of abstractions and/or formats. For instance, performing SelectionDAGISel on graph-ish IR while GlobalISel on linear IR. But, and this is a big BUT, it will almost certain to take years if not decades to change. There are already lost of discussions in the aforementioned talk on how to transit only the LLVM infrastructure – codegen not included – to MLIR and I believe the codegen part will not be easier.