See the previous published edition.
Welcome to the fifth issue of the MLIR (bi)Weekly, a newsletter (published on Friday) covering developments in MLIR, and related projects in the ecosystem. MLIR (bi)Weekly is brought to you by a collective effort of contributors, we welcome your contributions!
Highlights
- Flang has landed in the LLVM repository: we have now a frontend for MLIR in-tree!
- The Doxygen documentation is back online!
- Last week MLIR open meeting lead to a nice discussion on TCP! ( slides - recording)
- The consideration to relax CFG/SSA dominance from MLIR Region is back and lead to an extensive discussion.
- @stellaraccident shared an update on the Numpy dialect experiment.
- @qingyi proposes a mechanism like “Target Transform Info” interface for MLIR.
MLIR Core
Infrastructure
- Many utilities from within the MLIR support library have been migrated to the LLVM ADT.
- Documentation:
- More improvements to the layout of the website.
- MLIR passes are slowly gaining documentation
- No global constructors (e.g. static command line options) remain within the core lib/ directory.
- ClassID has been refactored into a cleaner TypeID class, and now works across shared libraries (but not across Windows DLLs yet).
- Passes can now specify their command line identifier directly, enabling the use of crash reproducers without the need for registration.
- A new applyOpPatternsAndFold method was added to allow applying patterns locally to a single operation.
Table-driven Infrastructure
- RewritePatterns can now guarantee when they have bounded recursion, enabling them to be recursively applied with dialect conversion.
- Optional operands and results are now supported.
- Operations with resizable operand lists can be expressed in ODS now.
- Location can now be specified in declarative rewrites (DRR).
Optimizations and Code Generation
- A “loop unswitching” pass/utility was added for affine for/if.
- An std.alloca was added to model stack/automatic allocations. The AutomaticAllocationScope trait on an operation indicates that the operation is creating a new allocation scope and control the lifetime of the allocations.
- Lowering of vector.broadcast has been refactored to be more progressive.
- 1-D vector transfer_read/write now lower to masked LLVM load/store instructions
- Vector.contract lowering to llvm matrix intrinsics now uses the newly introduced row-major mode. Followup will include per-argument control when ready in LLVM.
- A tool to generate named Linalg ops from a mathematically inspired notation has been added.
SPIR-V
- Better support for dynamic shape lowering is in working in progress.
- Array stride support is improved for both sized arrays and runtime arrays.
- A bug in serializer that caused the wrong phi parent block for back-to-back loops was fixed.
- The documentation is updated regarding availability and type conversion.
- A dialect-specific attribute is introduced for the interface variable ABI information to replace the existing dictionary attribute.
Other
Added support for OpenMP operations Taskwait, Taskyield.
In the Ecosystem
Flang, the LLVM Fortran Compiler
Flang has landed in the LLVM repository.
IREE : An Experimental MLIR Execution Environment
- New website has autogenerated IR and backend op coverage documentation.
- Op coverage tests run with new check framework allowing test coverage on ARM.
- npcomp: Some notes on high level API and pybind MLIR bindings with LLVM compat CMake build that may serve as inspiration for future upstreaming.
Recent Talks
- MLIR Open Meeting: GPU host dialect (slides - recording)
- MLIR Open Meeting: TCP Discussion ( slides - recording )
Recent Publications
- Next week ODM Talk (4/23) LLHD: A Multi-level Intermediate Representation for Hardware Description Languages
[2004.03494] LLHD: A Multi-level Intermediate Representation for Hardware Description Languages - http://llhd.io
Not using directly MLIR, but MLIR is cited:
This work has been in development over the past three years and predates efforts such as MLIR [17], which aims at providing a unifying frame- work for defining compiler IRs. The proposed concepts can likely be expressed in MLIR.