The Torch-MLIR project aims to provide first class support from the PyTorch ecosystem to the MLIR ecosystem.
 
 
 
 
 
 
Go to file
Sean Silva 370e3270ab Introduce `!torch.tensor` / `!torch.vtensor` types.
This removes our reliance on the numpy dialect and avoids our off-label
use of the builtin tnesor type for modeling unknown dtypes.  The
`!torch.vtensor` (`ValueTensorType`) type is a value-semantic tensor.
The `!torch.tensor` (`NonValueTensorType`) type is a non-value-semantic
tensor. The new types look as follows syntactically:

```
// Least-static-information, non-value-semantic tensor.
!torch.tensor
// Explicit form of least-static-information variant.
!torch.tensor<*,unk>
// Least-static-information, value-semantic tensor.
!torch.vtensor
// Explicit form of least-static-information variant.
!torch.vtensor<*,unk>
// Fixed-set of allowable element types, with first-class support for
// Torch's frontend signedness semantics.
!torch.tensor<*,si32>
// First-class support for unknown dtypes.
!torch.tensor<[?,?,?],unk>
// Standard MLIR representation of `?` for unknown dimensions.
!torch.tensor<[?,2,?,4],unk>
// Statically shaped / dtyped example.
!torch.vtensor<[1,2,3,4],f32>
```

This required fairly significant changes throughout the compiler, but
overall it is a big cleanup. We now have a much clearer layering of "the
Torch frontend lowering" vs "lowering to std + linalg + etc.".

At the C++ level, there is `ValueTensorType`, `NonValueTensorType`.
We also have a helper `BaseTensorType` (kind of like ShapedType) which
interoperates with those two.

Included changes:
- New `torch.tensor(dense<0.0> : tensor<5xf32>) : !torch.tensor` op for
  creating torch tensor literals in the frontend.
- Consistently use signedness for the types (except i1 which I didn't
  touch -- we need to sort out the situation with !basicpy.BoolType
  there anyway so will be attending to that soon)
- Frontend can annotate whether an argument to the function has value
  semantics. We currently require this, as our backend contract does not
  currently allow us to even model the non-value-semantic case. Before,
  the value-semantic assumption was randomly injected in the middle of
  the pass pipeline.
- Move ArrayToTensor (now called MaximizeValueSemantics) and
  RefinePublicReturn passes to torch dialect.
- The TorchToStd and TorchToLinalg passes are now type conversions from
  `!torch.vtensor` to `tensor` and use the dialect conversion infra.
  The overall conversion pipeline is set up following the best practices
  of the "Type Conversions the Not-So-Hard Way" talk. This required
  introducing `torch-func-builtin-tensorize` and
  `torch-finalizing-builtin-tensorize` passes analogous to the upstream
  bufferization passes with the corresponding names (mostly just
  copypasta from there).
- Misc Torch-level canonicalizations -- we now cleanly layer the
  lowering to std later in the pipeline, so we are gradually lessening
  our reliance on random std constant folding before we get to that
  point.

Recommended review order:
- New types in TorchTypes.td/TorchTypes.h/TorchDialect.cpp
- New ops in TorchOps.td / TorchOps.cpp
- Less important / more mechanical stuff
  - Frontend changes.
  - Pass changes/additions in `Torch/Transforms` and `Conversion/`
2021-06-10 10:56:48 -07:00
.github/workflows Revert "Skip torchvision 0.9.0 as it is incompatible with torch nightly" 2021-03-16 19:37:45 -07:00
build_tools Significantly restructure torch/aten import design. 2021-05-19 13:37:39 -07:00
cmake/modules Add install options for npcomp libraries and executables (#183) 2021-03-10 07:18:54 -08:00
docker/pytorch-nightly install pybind11 through pip to get version 2.6 (#173) 2021-02-28 16:19:03 -08:00
docs Add roadmap doc. 2021-03-15 14:43:51 -07:00
external Bump llvm-project to 35454268cf93f5561439980d6baeb27a874a380c 2021-05-19 14:00:38 -07:00
frontends Introduce `!torch.tensor` / `!torch.vtensor` types. 2021-06-10 10:56:48 -07:00
include Introduce `!torch.tensor` / `!torch.vtensor` types. 2021-06-10 10:56:48 -07:00
lib Introduce `!torch.tensor` / `!torch.vtensor` types. 2021-06-10 10:56:48 -07:00
python Significantly restructure torch/aten import design. 2021-05-19 13:37:39 -07:00
test Introduce `!torch.tensor` / `!torch.vtensor` types. 2021-06-10 10:56:48 -07:00
tools Add -pass-pipeline-crash-reproducer to npcomp-opt alias. 2021-05-10 18:06:16 -07:00
.clang-format Add stub numpy dialect. 2020-04-26 17:20:58 -07:00
.gitignore Add vim swap file in gitignore 2021-02-18 19:06:10 -08:00
.gitmodules Add mlir-hlo as a submodule and add a script to find versions. (#20) 2020-08-13 16:42:05 -07:00
.style.yapf Introduce a Target class and use it to define generic 32 and 64bit variants. 2020-06-13 14:43:10 -07:00
CMakeLists.txt Enable building using LLVM_EXTERNAL_PROJECTS. (#152) 2021-01-26 11:43:43 -07:00
LICENSE License and readme changes to align with inclusion in LLVM. (#1) 2020-07-31 20:53:09 -07:00
README.md README: mention installing nightly pytorch. 2021-04-27 11:37:09 -07:00

README.md

NPComp - MLIR based compiler toolkit for numerical python programs

This project is participating in the LLVM Incubator process: as such, it is not part of any official LLVM release. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project is not yet endorsed as a component of LLVM.

The NPComp project aims to provide tooling for compiling numerical python programs of various forms to take advantage of MLIR+LLVM code generation and backend runtime systems.

In addition to providing a bridge to a variety of Python based numerical programming frameworks, NPComp also directly develops components for tracing and compilation of generic Python program fragments.

Project Communication

Framework integrations

  • PyTorch -- Experimental integration for extracting programs from PyTorch.

Python language compiler tookit

At the core of NPComp are a set of dialects and python support code for tracing (define by run) numerical programs and compiling idiomatic subsets of the Python language. As another interpretation of the name, NPComp also seeks to provide compiler-backed support for Numpy APIs.

See the features doc for a semi-curated status of what is implemented in this area.

Architecture

The compiler is separated into:

  • Frontend importer: Translates from various AST levels to corresponding MLIR dialects.
  • Frontend compiler: MLIR passes and conversions, mostly operating on the basicpy and numpy dialects.
  • Backend compiler and runtime: Some effort has been taken to make this pluggable, but right now, only the IREE Backend exists. There is in-tree work to also build a minimal reference backend directly targeting LLVM.

Repository Layout

The project is roughly split into the following areas of code:

  • User-facing Python code
  • C++ include and lib trees, following LLVM/MLIR conventions
  • LIT testing trees:
    • test: Lit/FileCheck tests covering core MLIR based infra
    • test/Python/Compiler: Lit test suite that drive the compiler infra from Python
    • backend_test: Lit test suites conditionally enabled for each backend
  • tools: Scripts and binaries (npcomp-opt, npcomp-run-mlir, etc)

Interactive Use

The cmake configuration populates symlinks in the build/python directory mirroring the source layout. This allows edit-run without rebuilding (unless if files are added/removed).

Configuring the PYTHONPATH as above should be sufficient to run any interactive tooling (python3, Jupyter/Colab, etc).

Note that running the cmake_configure.sh script will also output a .env file in the workspace folder with the correct PYTHONPATH set. This allows tools like VSCode to work by default for debugging.

Notes:

  • Python sources are symlinked to the output directory at configure time. Adding sources will require a reconfigure. Editing should not.
  • It is a very common issue to have both python 2.7 (aka. "python") and python 3.x (aka. "python3") on a system at a time (and we can only hope that one day this ends). Since the native library at development time binds to a specific version, if you try to run with a different python, you will get an error about the "native" module not being found.

Compiler development

For bash users, adding the following to your .bashrc defines some aliases that are useful during compiler development, such as shortcuts for builing and running npcomp-opt.

source $WHERE_YOU_CHECKED_OUT_NPCOMP/tools/bash_helpers.sh

Build Instructions

Common prep

# From checkout directory.
git submodule init
git submodule update

# Use clang and lld to build (optional but recommended).
LLVM_VERSION=10
export CC=clang-$LLVM_VERSION
export CXX=clang++-$LLVM_VERSION
export LDFLAGS=-fuse-ld=$(which ld.lld-$LLVM_VERSION)

# Build and install LLVM/MLIR into the ./install-mlir directory
./build_tools/install_mlir.sh

Vanilla - numpy-only, no pytorch

# Follow common prep above.
./build_tools/cmake_configure.sh

# Build and run tests
# ./build_tools/test_all.sh runs all of these commands.
cd build
ninja
ninja check-npcomp

# cmake_configure.sh should emit a .env file with needed
# PYTHONPATH setup.
source .env

PyTorch Frontend

# Install PyTorch. We currently track and require the nighly build.
pip3 install --pre torch torchvision -f https://download.pytorch.org/whl/nightly/cpu/torch_nightly.html
# Build/test npcomp.
./build_tools/cmake_configure.sh
cmake --build build --target check-npcomp check-frontends-pytorch

PyTorch Frontend (via docker container)

Create docker image (or follow your own preferences):

  • Mount the (host) source directory to /src/mlir-npcomp (in the container).
  • Mount the /build directory (in the container) appropriately for your case.
docker build docker/pytorch-nightly --tag local/npcomp:build-pytorch-nightly
docker volume create npcomp-build

Shell into docker image:

docker run \
  --mount type=bind,source=$HOME/src/mlir-npcomp,target=/src/mlir-npcomp \
  --mount source=npcomp-build,target=/build \
  --rm -it local/npcomp:build-pytorch-nightly /bin/bash

Build/test npcomp (from within docker image):

# From within the docker image.
cd /src/mlir-npcomp
./build_tools/install_mlir.sh
./build_tools/cmake_configure.sh
cmake --build /build/npcomp --target check-npcomp check-frontends-pytorch

VSCode with a Docker Dev Image

Start a docker dev container based on our image

Assumes that mlir-npcomp is checked out locally under ~/src/mlir-npcomp. See docker_shell_funcs.sh for commands to modify if different.

# Build/start the container.
# Follow instructions here to allow running `docker` without `sudo`:
# https://docs.docker.com/engine/install/linux-postinstall/
source ./build_tools/docker_shell_funcs.sh
npcomp_docker_build  # Only needed first time/on updates to docker files.
npcomp_docker_start
# Get an interactive shell to the container and initial build.
npcomp_docker_login
# Stop the container (when done).
npcomp_docker_stop

Configure VSCode:

First, install the VSCode Docker extension and VSCode Remote - Containers extension. Follow instructions here to allow running docker without sudo, otherwise VSCode won't be able to use docker https://docs.docker.com/engine/install/linux-postinstall/ (Note that VSCode has some daemons that you will need to kill/restart for the instructions there to take effect; consider just rebooting your machine)

Attach to your running container by opening the Docker extension tab (left panel), right clicking on the container name, and selecting "Attach Visual Studio code". The container name if you are using docker_shell_funcs.sh is npcomp.

Install extensions in container:

  • CMake Tools
  • C/C++
  • C++ Intellisense

Add workspace folders:

  • mlir-npcomp source folder
  • external/llvm-project source folder

Configure general settings:

Ctrl-Shift-P > Preferences: Open Settings (UI)

  • For mlir-npcomp folder:
    • Cmake: Build directory: /build/npcomp
    • Uncheck Cmake: Configure On Edit and Cmake: Configure on Open
  • For llvm-project folder:
    • Cmake: Build directory: /build/llvm-build
    • Uncheck Cmake: Configure On Edit and Cmake: Configure on Open

Configure Intellisense:

Ctrl-Shift-P > C/C++: Edit Configurations (UI)

  • Open C/C++ config (for each project folder):
    • Under Advanced, Compile Commands:
      • set /build/npcomp/compile_commands.json for mlir-npcomp
      • set /build/llvm-build/compile_commands.json for llvm-project
  • Open a C++ file, give it a few seconds and see if you get code completion (press CTRL-Space).

Make sure to save your workspace (prefer a local folder with the "Use Local" button)!