4 ms·
The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent t
by atq2119 7y ago
The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent the world rather than bringing the ideas to LLVM itself.
- auggierose 7y agoWhatever it is, can't be NIH given that Chris Lattner invented LLVM ...
- atq2119 7y agoThen call it reinventing the wheel. It still deserves to be weighed properly against the alternatives.
- adwn 7y agoModifying/extending LLVM is very hard to infeasible when the problem is with the fundamental architectural design. For example, according to the MLIR project, parallel compilation of a compile unit is basically not possible with LLVM.
- atq2119 7y agoThey refer mostly to how globals and constants maintain use lists as linked lists, which is indeed a nightmare for synchronization. And yes, fixing that would require some difficult surgery. But let's be honest about what is more work: refactoring that, or rewriting all users of LLVM out there. My bet is on the first one being cheaper by at least three orders of magnitude.
- detaro 7y agoExperimentation in something easier to change than LLVM to make sure they know what exactly they want to do to LLVM later?
- wolfgke 7y ago> The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent the world rather than bringing the ideas to LLVM itself. What if your idea is completely opposite to LLVM's goals? For example, you want a very small (e.g. in the sense of LOC) compiler?
- imtringued 7y agoI don't know why but for some reason everyone loves to shout "NIH" complaints on HN. I don't believe in the success of MLIR but there is no reason to not attempt a fresh start. LLVM is a gigantic project that would have to be significantly rewritten to make MLIR possible. Your development team would need a lot of LLVM expertise even though it doesn't care about LLVM. The end result would be something completely different from LLVM so what benefit is there to base it on LLVM? It's not like the rust compiler will automatically update to MLIR just because MLIR is a descendant of LLVM IR. LLVM IR is also clearly not suitable for anything other than LLVM. It failed in the browser (Webassembly won), it failed for GPUs (SPIR-V is its own thing) and now it might fail again when it is replaced by MLIR. There is clearly demand for something that is better than LLVM IR.
- enos_feedler 7y agoLLVM IR wasn't competing with WebAssembly. WebAssembly is designed as an abstract machine _target_ instruction set whereas LLVM IR is an abstract _internal_ intermediate instruction set for compiler passes. I think they fit nice together but don't have deep expertise in either of these IRs, just general compilers.
- atq2119 7y agoA similar argument applies to SPIR-V. While I believe Apple are still trying to use LLVM bitcode for some purposes, the reality is that for a spec like Vulkan, you really want a shader program representation that is properly designed with a view to compatibility and independent extensibility (in the sense of hardware or platform vendor extensions), which LLVM IR isn't, pretty much on purpose.
- enos_feedler 7y agoIt makes sense to me that SPIR-V be a complete instruction set for an abstract GPU shader core. You can then have a GPU compiler translate to raw shader instructions. Much like a WASM compiler can translate from wasm to raw CPU instructions. I think an important design consideration in either case is "no surprises" meaning the translation should be fairly tight and predictable and serve just to smooth out some small surface area differences. If they do any funky magic/startling behavior the combined stack will start to exhibit weird performance properties