The Torch-MLIR project aims to provide first class support from the PyTorch ecosystem to the MLIR ecosystem.
 
 
 
 
 
 
Go to file
Sean Silva 75f57b461e
Totally rework RefE2E tensor to memref flow. (#42)
This now gets the overall "RefE2E" compilation stack to a point that I'm
fairly happy with. We simplify it by mostly embracing the "descriptor"
view of the world.

The overall flow is best understood by reading through the
createE2ELoweringPipeline function in lib/E2E/E2E.cpp
That function creates a pass pipeline that lowers from "TCF" (which is
~numpy level of abstraction) down to LLVM IR.

A brief high-level summary of what happens there:

1. TCF to TCP conversion. This involves reifying error handling in the
form of shape constraints. See test/Conversion/TCFToTCP/basic.mlir

2. Lowering shape constraints. This converts shape constraints into
eager error-handling code. See test/E2E/lower-shape-constraints.mlir
This pass will soon go upstream.
Because this lowers to std.assert, some later passes like
LowerToNpcomprtABI and LowerToLLVM are updated to properly plumb this
through e2e.
See test/npcomp-run-mlir/invalid-broadcast.mlir for an execution test
that properly aborts in case of an error.

3. Lowering tensors to memrefs. This is done via a series of passes
rather than an single mega conversion. Unlike the previous code that
mixed in the npcomprt ABI stuff here, it's now a very clean "pure
memref" conversion.
See test/E2E/lower-*-to-memref.mlir and
lib/E2E/TensorToMemref/
Most of the changes are concentrated here.

4. As part of the above, we use the upstream ConvertShapeToStandard for
lowering shapes.

5. We lower linalg to loops and lower loops to CFG using upstream
passes.

6. Rewrite the "ABI" boundaries of the program to npcomprt data
structures (LowerToNpcomprtABI). This mainly affects ABI boundaries and
how global tensor constants are represented. One of the major
improvements in this commit is that now it's a very clean rewrite that
just replaces memrefs on ABI boundaries with !npcomprt.tensor (before
there was a get_extent function that is not needed).
See test/E2E/lower-to-npcomprt-abi.mlir

7. Lower to LLVM with upstream mlir patterns + some patterns for the
npcomprt lowerings.

One aspect here that is still a remnant of a non-descriptor-based tensor
to memref flow is the BypassShapes + LowerShapedResultsToMemref.
BypassShapes wraps the "tensor compute" ops in a tcp.shaped_results
(basically a "tie_shape" kind of op), and then
LowerShapedResultsToMemref uses those annotations to allocate output
buffers while lowering the "tensor compute ops". Note that there are
very few "tensor compute" ops currently supported (tcp.add +
tcp.broadcast_to), so we just hardcode them in both passes.
Realistically, I expect this to go away as we fully embrace the
descriptor-based approach for simplicity, so don't look too deep into
it.
2020-09-16 17:31:40 -07:00
.github/workflows Move precommit to 20.04 (#15) 2020-08-07 10:32:02 -07:00
build_tools Update build instructions to use the submodule for llvm. 2020-08-28 16:20:55 -07:00
cmake/modules Fix some compiler option and warning levels. 2020-07-04 17:38:01 -07:00
docs Update broken links 2020-08-04 18:55:46 -07:00
external Bump LLVM to @7d1ed69 and fix namespace handling changed upstream. 2020-09-16 15:52:15 -07:00
frontends Make code that depends on the legacy "type dispatch" mechanism optional. (#32) 2020-08-26 12:55:16 -07:00
include/npcomp Totally rework RefE2E tensor to memref flow. (#42) 2020-09-16 17:31:40 -07:00
lib Totally rework RefE2E tensor to memref flow. (#42) 2020-09-16 17:31:40 -07:00
python Add a new python script to auto-generate ATen op ODS definitions. (#43) 2020-09-16 16:21:24 -07:00
test Totally rework RefE2E tensor to memref flow. (#42) 2020-09-16 17:31:40 -07:00
tools Bump submodule versions. 2020-09-08 13:26:42 -07:00
.clang-format Add stub numpy dialect. 2020-04-26 17:20:58 -07:00
.gitignore Add MLIRContext.dense_elements_attr to create an attribute from a python buffer/array. 2020-05-08 17:36:07 -07: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 Add pytorch interface to ATen Dialect (#30) 2020-08-21 11:22:47 -07:00
Dockerfile Make code that depends on the legacy "type dispatch" mechanism optional. (#32) 2020-08-26 12:55:16 -07:00
LICENSE License and readme changes to align with inclusion in LLVM. (#1) 2020-07-31 20:53:09 -07:00
README.md Update build instructions to use the submodule for llvm. 2020-08-28 16:20:55 -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.

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)

Quick start

git submodule init
git submodule update

LLVM_VERSION=10
export CC=clang-$LLVM_VERSION
export CXX=clang++-$LLVM_VERSION
export LDFLAGS=-fuse-ld=$(which ld.lld-$LLVM_VERSION)

./build_tools/install_mlir.sh
./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

# Setup PYTHONPATH for interactive use
export PYTHONPATH="$(realpath build/python):$(realpath build/iree/bindings/python)"

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