4 ms·

How does migrating to MLIR address the problem?

pjmlp 1y ago
The higher abstraction level it provides over the LLVM IR, making language frontends and compiler passes less dependent on its semantics.
- AndyKelley 1y ago
  Huh?? That can only make frontends' jobs more tricky.
  - pjmlp 1y ago
    Yet is being embraced by everyone since its introduction in 2019, with its own organization and conference talks. So maybe all those universities, companies and the LLVM project know kind of what they are doing. - https://mlir.llvm.org/ https://mlir.llvm.org/ - https://llvm.github.io/clangir/ https://llvm.github.io/clangir/ - https://mlir.llvm.org/talks/ https://mlir.llvm.org/talks/
    - AndyKelley 1y ago
      No need to make a weird appeal to authority. Can you just explain the answer to my question in your own words?
      - marcelroed 1y ago
        I am only familiar with MLIR for accelerator-specific compilation, but my understanding is that by describing operations at a higher level, you don’t need the frontend to know what LLVM IR will lead to the best final performance. For instance you could say "perform tiled matrix multiplication" instead of "multiply and add while looping in this arbitrary indexing pattern", and an MLIR pass can reason about what pattern to use and take whatever hints you’ve given it. This is especially helpful when some implementations should be different depending on previous/next ops and what your target hardware is. I think there’s no reason Zig can’t do something like this internally, but MLIR is an existing way to build primitives at several different levels of abstraction. From what I’ve heard it’s far from ergonomic for compiler devs, though…
      - pjmlp 1y ago
        You see it as appeal to authority, I see it as the community of frontend developers, based on Swift and Rust integration experience, and work done by Chris Lattner, while working at Google, feedbacking into what the evolution of LLVM IR is supposed to look like. Mojo and Flang, were designed from scratch using MLIR, as there are many other newer languages on the LLVM ecosystem. I see it as the field experience of folks that know a little bit more than I ever will about compiler design.
- alexrp 1y ago
  As the guy currently handling Zig's LLVM upgrades, I do not see this as an advantage at all. The more IR layers I have to go through to diagnose miscompilations, the more of a miserable experience it becomes. I don't know that I would have the motivation to continue doing the upgrades if I also had to deal with MLIR.
  - pjmlp 1y ago
    LLVM project sees that otherwise, and the adoption across the LLVM community is quite telling where they stand.
    - alexrp 1y ago
      That doesn't seem like a good argument for why Zig ought to target MLIR instead of LLVM IR. I think I'd like to see some real-world examples of compilers for general-purpose programming languages using MLIR (ClangIR is still far from complete) before I entertain this particular argument.
      - pjmlp 1y ago
        Would Flang do it? Fortran was once general purpose. https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md https://github.com/llvm/llvm-project/blob/main/flang/docs/Hi... Maybe the work in Swift (SIL), Rust (MIR), Julia (SSAIR) that were partially the inspiration for MLIR, alongside work done at Google designing Tensorflow compiler? The main goal being an IR that would accomodate all use cases of those high level IRs. Here are the presentation talk slides at European LLVM Developers Meeting back in 2019, https://llvm.org/devmtg/2019-04/slides/Keynote-ShpeismanLattner-MLIR.pdf https://llvm.org/devmtg/2019-04/slides/Keynote-ShpeismanLatt... Also you can find many general purpose enough users around this listing, https://mlir.llvm.org/users/ https://mlir.llvm.org/users/
        pklausler 1y ago
        Are you saying that Fortran was once a general purpose programming language, but somehow changed to no longer be one?

The higher abstraction level it provides over the LLVM IR, making language frontends and compiler passes less dependent on its semantics.

AndyKelley 1y ago
Huh?? That can only make frontends' jobs more tricky.
- pjmlp 1y ago
  Yet is being embraced by everyone since its introduction in 2019, with its own organization and conference talks. So maybe all those universities, companies and the LLVM project know kind of what they are doing. - https://mlir.llvm.org/ https://mlir.llvm.org/ - https://llvm.github.io/clangir/ https://llvm.github.io/clangir/ - https://mlir.llvm.org/talks/ https://mlir.llvm.org/talks/
  - AndyKelley 1y ago
    No need to make a weird appeal to authority. Can you just explain the answer to my question in your own words?
    - marcelroed 1y ago
      I am only familiar with MLIR for accelerator-specific compilation, but my understanding is that by describing operations at a higher level, you don’t need the frontend to know what LLVM IR will lead to the best final performance. For instance you could say "perform tiled matrix multiplication" instead of "multiply and add while looping in this arbitrary indexing pattern", and an MLIR pass can reason about what pattern to use and take whatever hints you’ve given it. This is especially helpful when some implementations should be different depending on previous/next ops and what your target hardware is. I think there’s no reason Zig can’t do something like this internally, but MLIR is an existing way to build primitives at several different levels of abstraction. From what I’ve heard it’s far from ergonomic for compiler devs, though…
    - pjmlp 1y ago
      You see it as appeal to authority, I see it as the community of frontend developers, based on Swift and Rust integration experience, and work done by Chris Lattner, while working at Google, feedbacking into what the evolution of LLVM IR is supposed to look like. Mojo and Flang, were designed from scratch using MLIR, as there are many other newer languages on the LLVM ecosystem. I see it as the field experience of folks that know a little bit more than I ever will about compiler design.
alexrp 1y ago
As the guy currently handling Zig's LLVM upgrades, I do not see this as an advantage at all. The more IR layers I have to go through to diagnose miscompilations, the more of a miserable experience it becomes. I don't know that I would have the motivation to continue doing the upgrades if I also had to deal with MLIR.
- pjmlp 1y ago
  LLVM project sees that otherwise, and the adoption across the LLVM community is quite telling where they stand.
  - alexrp 1y ago
    That doesn't seem like a good argument for why Zig ought to target MLIR instead of LLVM IR. I think I'd like to see some real-world examples of compilers for general-purpose programming languages using MLIR (ClangIR is still far from complete) before I entertain this particular argument.
    - pjmlp 1y ago
      Would Flang do it? Fortran was once general purpose. https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md https://github.com/llvm/llvm-project/blob/main/flang/docs/Hi... Maybe the work in Swift (SIL), Rust (MIR), Julia (SSAIR) that were partially the inspiration for MLIR, alongside work done at Google designing Tensorflow compiler? The main goal being an IR that would accomodate all use cases of those high level IRs. Here are the presentation talk slides at European LLVM Developers Meeting back in 2019, https://llvm.org/devmtg/2019-04/slides/Keynote-ShpeismanLattner-MLIR.pdf https://llvm.org/devmtg/2019-04/slides/Keynote-ShpeismanLatt... Also you can find many general purpose enough users around this listing, https://mlir.llvm.org/users/ https://mlir.llvm.org/users/
      - pklausler 1y ago
        Are you saying that Fortran was once a general purpose programming language, but somehow changed to no longer be one?