| commit | 525376960fcda8f155fe738e206e4d0be38a8492 | [log] [tgz] |
|---|---|---|
| author | River Riddle <riverriddle@google.com> | Fri Nov 01 14:47:42 2019 -0700 |
| committer | A. Unique TensorFlower <gardener@tensorflow.org> | Fri Nov 01 14:48:16 2019 -0700 |
| tree | 2d138e91319dd8200814bbcf0576c5da5caa8ed2 | |
| parent | 38c2a50d42e5243705ad7495da0c3a6cb9bbe40d [diff] |
Add DialectAsmParser/Printer classes to simplify dialect attribute and type parsing. These classes are functionally similar to the OpAsmParser/Printer classes and provide hooks for parsing attributes/tokens/types/etc. This change merely sets up the base infrastructure and updates the parser hooks, followups will add hooks as needed to simplify existing handrolled dialect parsers. This has various different benefits: *) Attribute/Type parsing is much simpler to define. *) Dialect attributes/types that contain other attributes/types can now use aliases. *) It provides a 'spec' with which we may use in the future to auto-generate parsers/printers. *) Error messages emitted by attribute/type parsers can provide character exact locations rather than "beginning of the string" PiperOrigin-RevId: 278005322
The MLIR project aims to define a common intermediate representation (IR) that will unify the infrastructure required to execute high performance machine learning models in TensorFlow and similar ML frameworks. This project will include the application of HPC techniques, along with integration of search algorithms like reinforcement learning. This project aims to reduce the cost to bring up new hardware, and improve usability for existing TensorFlow users.
Note that this repository contains the core of the MLIR framework. The TensorFlow compilers we are building on top of MLIR will be part of the main TensorFlow repository soon.
Thank you for your interest in contributing to MLIR! If you want to contribute to MLIR, be sure to review the contribution guidelines.
For more information on MLIR, please see:
Join the MLIR mailing list to hear about announcements and discussions.
We also have an MLIR SIG which was created to enable collaboration and form a strong engineering-driven open community. We have weekly ‘Open Design Meetings’. If you’d like to discuss a particular topic or have questions, please add it to the agenda doc. Details on how to join the meeting are in the agenda doc. You should also get an invite when you join the mailing list.
Please be mindful of the TensorFlow Code of Conduct, which pledges to foster an open and welcoming environment.
MLIR is intended to be a hybrid IR which can support multiple different requirements in a unified infrastructure. For example, this includes:
MLIR is a common IR that also supports hardware specific operations. Thus, any investment into the infrastructure surrounding MLIR (e.g. the compiler passes that work on it) should yield good returns; many targets can use that infrastructure and will benefit from it.
MLIR is a powerful representation, but it also has non-goals. We do not try to support low level machine code generation algorithms (like register allocation and instruction scheduling). They are a better fit for lower level optimizers (such as LLVM). Also, we do not intend MLIR to be a source language that end-users would themselves write kernels in (analogous to CUDA C++). While we would love to see a kernel language happen someday, that will be an independent project that compiles down to MLIR.
We benefited from experience gained from building other IRs (HLO, LLVM and SIL) when building MLIR. We will directly adopt existing best practices, e.g. writing and maintaining an IR spec, building an IR verifier, providing the ability to dump and parse MLIR files to text, writing extensive unit tests with the FileCheck tool, and building the infrastructure as a set of modular libraries that can be combined in new ways. We plan to use the infrastructure developed by the XLA team for performance analysis and benchmarking.
Other lessons have been incorporated and integrated into the design in subtle ways. For example, LLVM has non-obvious design mistakes that prevent a multithreaded compiler from working on multiple functions in an LLVM module at the same time. MLIR solves these problems by having per-function constant pools and by making references explicit with function_ref.
The following instructions for compiling and testing MLIR assume that you have git, ninja, and a working C++ toolchain. In the future, we aim to align on the same level of platform support as LLVM. For now, MLIR has been tested on Linux and macOS, with recent versions of clang and with gcc 7.
git clone https://github.com/llvm/llvm-project.git git clone https://github.com/tensorflow/mlir llvm-project/llvm/projects/mlir mkdir llvm-project/build cd llvm-project/build cmake -G Ninja ../llvm -DLLVM_BUILD_EXAMPLES=ON -DLLVM_TARGETS_TO_BUILD="host" cmake --build . --target check-mlir
To compile and test on Windows using Visual Studio 2017:
REM In shell with Visual Studio environment set up, e.g., with command such as REM $visual-studio-install\Auxiliary\Build\vcvarsall.bat" x64 REM invoked. git clone https://github.com/llvm/llvm-project.git git clone https://github.com/tensorflow/mlir llvm-project\llvm\projects\mlir mkdir llvm-project\build cd llvm-project\build cmake ..\llvm -G "Visual Studio 15 2017 Win64" -DLLVM_BUILD_EXAMPLES=ON -DLLVM_TARGETS_TO_BUILD="host" -DCMAKE_BUILD_TYPE=Release -Thost=x64 cmake --build . --target check-mlir
As a starter, you may try the tutorial on building a compiler for a Toy language.