{"slug": "mlir", "name": "MLIR", "category": "infra", "category_name": "Infrastructure and DevOps", "description": "", "recommenders": 5, "commenters": 7, "warners": 0, "score": 4.87, "rising": 1.02, "first": "2025-12-21", "latest": "2026-10-11", "why": "MLIR does give me the feeling of \"an IR to rule them all\"", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 5, "neutral": 0, "compare": 2, "warn": 0}, "spark": [0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 0, 1], "listed": true, "loved": [], "caveat": "", "short_quote": "MLIR does give me the feeling of \"an IR to rule them all\"", "kind": "", "icon": true, "domain": "llvm.org", "github_repo": null, "official_url": "https://mlir.llvm.org", "pricing": "", "aliases": ["MLIR"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 800695040, "item_id": 50043440, "url": "https://news.ycombinator.com/item?id=50043440", "by": "verdagon", "date": "2026-10-11", "stance": "recommend", "quote": "since MLIR has so many backends", "excerpt": "GPU compilation is definitely something I intend Valen to support. I wrote about it back in 2022, [0] and I learned a lot of lessons on how to do it (and how not to do it!) from working on the Mojo compiler. The biggest decision for Valen is what to lower to: * Rust MIR, since rustc has CUDA now, [1] (perhaps other cards soon?) * SPIR-V, like Zig does for its GPU compilation [2] * MLIR Rust MIR is looking pretty nice", "context": "", "use_case": "", "switched_from": "", "story": "Valen's Memory Safety: A New Kind of Borrow Checking"}, {"id": 789817776, "item_id": 49363611, "url": "https://news.ycombinator.com/item?id=49363611", "by": "flakiness", "date": "2026-08-19", "stance": "recommend", "quote": "MLIR which is so prevalent in the ML compile stack everywhere", "excerpt": "Also MLIR which is so prevalent in the ML compile stack everywhere. https://mlir.llvm.org/", "context": "", "use_case": "ML compiler infrastructure", "switched_from": "", "story": "The Mojo language (by Modular, now Qualcomm) is now open-source"}, {"id": 769632272, "item_id": 48102017, "url": "https://news.ycombinator.com/item?id=48102017", "by": "alecco", "date": "2026-05-11", "stance": "recommend", "quote": "There's a recent NVIDIA MLIR that is quite good and fast.", "excerpt": "> directly to PTX Weird. There's a recent NVIDIA MLIR that is quite good and fast. Or they could target the even easier and more recent/fashionable tile IR [1] used by CuTile [2] (a little bit higher level but significantly easier to target, only loses on epilogue fusion and similar). [1] https://docs.nvidia.com/cuda/tile-ir/ [2] https://developer.nvidia.com/cuda/tile", "context": "", "use_case": "", "switched_from": "", "story": "CUDA-oxide: Nvidia's official Rust to CUDA compiler"}, {"id": 744479344, "item_id": 46529959, "url": "https://news.ycombinator.com/item?id=46529959", "by": "GZGavinZhao", "date": "2026-01-07", "stance": "recommend", "quote": "MLIR does give me the feeling of \"an IR to rule them all\"", "excerpt": "> There is third approach, established by a group in Minnesota [1], which is to design languages and tools which are modular and extensible from the get-go, so that extensions are more interoperable. They do research on how to make this work using attribute grammars. MLIR [1] has entered the chat :P I know I know MLIR is an IR and not a programming language, but MLIR does give me the feeling of \"an IR to rule them al", "context": "", "use_case": "", "switched_from": "", "story": "Stop Designing Languages. Write Libraries Instead (2016)"}, {"id": 741601073, "item_id": 46350067, "url": "https://news.ycombinator.com/item?id=46350067", "by": "sueszli", "date": "2025-12-21", "stance": "recommend", "quote": "i think you might be interested in MLIR/IREE", "excerpt": "a heap-free implementation could be a really cool direction to explore. thanks! i think you might be interested in MLIR/IREE: https://github.com/openxla/iree", "context": "", "use_case": "ML compiler infrastructure", "switched_from": "", "story": "Show HN: Autograd.c \u2013 A tiny ML framework built from scratch"}]}], "caveats": [], "who": [], "tags": [], "use_cases": ["ml compiler infrastructure", "compiler ir"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=50042362", "title": "Valen's Memory Safety: A New Kind of Borrow Checking", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49800085", "title": "Fearless SIMD v1.0", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49358327", "title": "The Mojo language (by Modular, now Qualcomm) is now open-source", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48962600", "title": "UnifiedIR for Julia", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48096692", "title": "CUDA-oxide: Nvidia's official Rust to CUDA compiler", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46525640", "title": "Stop Designing Languages. Write Libraries Instead (2016)", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"recommend": 1}, "2026-01": {"recommend": 1}, "2026-02": {}, "2026-03": {}, "2026-04": {}, "2026-05": {"recommend": 1}, "2026-06": {}, "2026-07": {"compare": 1}, "2026-08": {"recommend": 1}, "2026-09": {"compare": 1}, "2026-10": {"recommend": 1}}, "quotes": [{"id": 800695040, "item_id": 50043440, "url": "https://news.ycombinator.com/item?id=50043440", "by": "verdagon", "date": "2026-10-11", "stance": "recommend", "quote": "since MLIR has so many backends", "excerpt": "GPU compilation is definitely something I intend Valen to support. I wrote about it back in 2022, [0] and I learned a lot of lessons on how to do it (and how not to do it!) from working on the Mojo compiler. The biggest decision for Valen is what to lower to: * Rust MIR, since rustc has CUDA now, [1] (perhaps other cards soon?) * SPIR-V, like Zig does for its GPU compilation [2] * MLIR Rust MIR is looking pretty nice", "context": "", "use_case": "", "switched_from": "", "story": "Valen's Memory Safety: A New Kind of Borrow Checking"}, {"id": 797399840, "item_id": 49837490, "url": "https://news.ycombinator.com/item?id=49837490", "by": "0xdeafbeef", "date": "2026-09-24", "stance": "compare", "quote": "Sounds similar to https://mlir.llvm.org/", "excerpt": "Sounds similar to https://mlir.llvm.org/", "context": "", "use_case": "", "switched_from": "", "story": "Fearless SIMD v1.0"}, {"id": 789817776, "item_id": 49363611, "url": "https://news.ycombinator.com/item?id=49363611", "by": "flakiness", "date": "2026-08-19", "stance": "recommend", "quote": "MLIR which is so prevalent in the ML compile stack everywhere", "excerpt": "Also MLIR which is so prevalent in the ML compile stack everywhere. https://mlir.llvm.org/", "context": "", "use_case": "ML compiler infrastructure", "switched_from": "", "story": "The Mojo language (by Modular, now Qualcomm) is now open-source"}, {"id": 783520128, "item_id": 48970008, "url": "https://news.ycombinator.com/item?id=48970008", "by": "KenoFischer", "date": "2026-07-19", "stance": "compare", "quote": "Not using MLIR here is more about other considerations", "excerpt": "I don't think there's anything we need to do here that couldn't be expressed in MLIR representationally. That said, I also haven't studied MLIR's representation in too much detail myself, so it's possible there's subtle corner cases. For example, in LLVM you end up getting quadratic processing times even for linear time passes, because it needs to restore the ordering count for instructions (I think the trick in this", "context": "works on Julia compiler", "use_case": "compiler IR", "switched_from": "", "story": "UnifiedIR for Julia"}, {"id": 769632272, "item_id": 48102017, "url": "https://news.ycombinator.com/item?id=48102017", "by": "alecco", "date": "2026-05-11", "stance": "recommend", "quote": "There's a recent NVIDIA MLIR that is quite good and fast.", "excerpt": "> directly to PTX Weird. There's a recent NVIDIA MLIR that is quite good and fast. Or they could target the even easier and more recent/fashionable tile IR [1] used by CuTile [2] (a little bit higher level but significantly easier to target, only loses on epilogue fusion and similar). [1] https://docs.nvidia.com/cuda/tile-ir/ [2] https://developer.nvidia.com/cuda/tile", "context": "", "use_case": "", "switched_from": "", "story": "CUDA-oxide: Nvidia's official Rust to CUDA compiler"}, {"id": 744479344, "item_id": 46529959, "url": "https://news.ycombinator.com/item?id=46529959", "by": "GZGavinZhao", "date": "2026-01-07", "stance": "recommend", "quote": "MLIR does give me the feeling of \"an IR to rule them all\"", "excerpt": "> There is third approach, established by a group in Minnesota [1], which is to design languages and tools which are modular and extensible from the get-go, so that extensions are more interoperable. They do research on how to make this work using attribute grammars. MLIR [1] has entered the chat :P I know I know MLIR is an IR and not a programming language, but MLIR does give me the feeling of \"an IR to rule them al", "context": "", "use_case": "", "switched_from": "", "story": "Stop Designing Languages. Write Libraries Instead (2016)"}, {"id": 741601073, "item_id": 46350067, "url": "https://news.ycombinator.com/item?id=46350067", "by": "sueszli", "date": "2025-12-21", "stance": "recommend", "quote": "i think you might be interested in MLIR/IREE", "excerpt": "a heap-free implementation could be a really cool direction to explore. thanks! i think you might be interested in MLIR/IREE: https://github.com/openxla/iree", "context": "", "use_case": "ML compiler infrastructure", "switched_from": "", "story": "Show HN: Autograd.c \u2013 A tiny ML framework built from scratch"}]}