[mlir] Re: "MLIR meets LLVM" Round-Table at the LLVM Dev Meeting

Hi all,

As a reminder, the round-table will be Tuesday, Oct 22, 10:20-11:30, see here: http://llvm.org/devmtg/2019-10/#round

Here is a potential list of all the topics I gathered from everyone, let me know if I missed anything.

  • Intro, practical aspect of the integration (repository, etc.)
  • Can we have a machine-readable definition of LLVM IR in LLVM itself: instructions, tracking changes, altering the semantics in the dialect wrt LLVM IR. We could reuse this for the MLIR LLVM Dialect.
  • Clang: would the static analyzer be a good candidate for a project to be playing with a MLIR Dialect?
  • Using MLIR for SCEV, VPLAN, etc. Isn’t SCEV an IR?
  • MIR: could/should it be reimplemented as a MLIR dialect?
  • What about Alive? (If Alive folks are around?)
  • Representing parallelism in MLIR
  • Heterogeneous compilation: this includes GPU of course, but also more exotic platforms / third-party accelerator: how to plug all this into a codegen story?
  • Using MLIR dialects as a testbed for proposed LLVM IR changes (there were proposals of tensor types for LLVM for example).
  • Using MLIR for loop optimization and other higher-level transformations, e.g. doing LLVM->Polly->MLIR Affine->LLVM.-

Note also that at shortly after the round-table, at 12:05pm the talk about An MLIR Dialect for High-Level Optimization of Fortran will take place.

Best,

Hi all,

As a reminder, the round-table will be Tuesday, Oct 22, 10:20-11:30, see here: http://llvm.org/devmtg/2019-10/#round

Here is a potential list of all the topics I gathered from everyone, let me know if I missed anything.

  • Intro, practical aspect of the integration (repository, etc.)
  • Can we have a machine-readable definition of LLVM IR in LLVM itself: instructions, tracking changes, altering the semantics in the dialect wrt LLVM IR. We could reuse this for the MLIR LLVM Dialect.

The need for a machine-readable description of LLVM IR in LLVM itself has come up in past discussions re: the function merging pass. When LLVM IR is extended, it would be great if the function comparator utility automatically learned which IR properties to diff instead of silently miscompiling.

vedant