2020-08-05 20:36:16 +08:00
|
|
|
add_subdirectory(CAPI)
|
2019-05-18 06:03:39 +08:00
|
|
|
add_subdirectory(EDSC)
|
2019-05-21 22:22:35 +08:00
|
|
|
add_subdirectory(mlir-cpu-runner)
|
|
|
|
|
add_subdirectory(SDBM)
|
2019-06-25 05:35:21 +08:00
|
|
|
add_subdirectory(lib)
|
2019-05-14 01:59:04 +08:00
|
|
|
|
2019-04-03 01:02:07 +08:00
|
|
|
llvm_canonicalize_cmake_booleans(
|
Initial boiler-plate for python bindings.
Summary:
* Native '_mlir' extension module.
* Python mlir/__init__.py trampoline module.
* Lit test that checks a message.
* Uses some cmake configurations that have worked for me in the past but likely needs further elaboration.
Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes
Tags: #mlir
Differential Revision: https://reviews.llvm.org/D83279
2020-07-07 14:05:46 +08:00
|
|
|
MLIR_BINDINGS_PYTHON_ENABLED
|
2019-04-03 01:02:07 +08:00
|
|
|
LLVM_BUILD_EXAMPLES
|
Add missing CMake bool canonicalizations.
Summary:
* This allows these flags to be passed on the command line with normal CMake bool-interpreted values like ON/OFF instead of requiring 0/1.
* As-is, if passing ON/OFF, these will cause a parse error in lit.site.cfg.py because Python tries to interpret the string literally.
Reviewers: stephenneuendorffer
Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, grosul1, Kayjukh, jurahul, msifontes
Tags: #mlir
Differential Revision: https://reviews.llvm.org/D83451
2020-07-09 08:54:56 +08:00
|
|
|
MLIR_CUDA_CONVERSIONS_ENABLED
|
|
|
|
|
MLIR_CUDA_RUNNER_ENABLED
|
|
|
|
|
MLIR_ROCM_CONVERSIONS_ENABLED
|
|
|
|
|
MLIR_ROCM_RUNNER_ENABLED
|
|
|
|
|
MLIR_VULKAN_RUNNER_ENABLED
|
2019-04-03 01:02:07 +08:00
|
|
|
)
|
|
|
|
|
|
2019-05-16 00:26:27 +08:00
|
|
|
# Passed to lit.site.cfg.py.in to set up the path where to find the libraries
|
|
|
|
|
# for linalg integration tests.
|
2019-11-27 00:47:14 +08:00
|
|
|
set(MLIR_DIALECT_LINALG_INTEGRATION_TEST_LIB_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
|
2020-03-27 17:20:05 +08:00
|
|
|
set(MLIR_RUNNER_UTILS_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
|
2019-05-16 00:26:27 +08:00
|
|
|
|
2019-07-04 22:49:52 +08:00
|
|
|
# Passed to lit.site.cfg.py.in to set up the path where to find the libraries
|
[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype
This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.
- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.
- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).
- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.
Reviewed By: ftynse, mravishankar
Differential Revision: https://reviews.llvm.org/D86108
2020-10-23 22:46:18 +08:00
|
|
|
# for the mlir cuda / rocm / spirv / vulkan runner tests.
|
2019-11-27 00:47:14 +08:00
|
|
|
set(MLIR_CUDA_WRAPPER_LIBRARY_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
|
[mlir][gpu] Introduce mlir-rocm-runner.
Summary:
`mlir-rocm-runner` is introduced in this commit to execute GPU modules on ROCm
platform. A small wrapper to encapsulate ROCm's HIP runtime API is also inside
the commit.
Due to behavior of ROCm, raw pointers inside memrefs passed to `gpu.launch`
must be modified on the host side to properly capture the pointer values
addressable on the GPU.
LLVM MC is used to assemble AMD GCN ISA coming out from
`ConvertGPUKernelToBlobPass` to binary form, and LLD is used to produce a shared
ELF object which could be loaded by ROCm HIP runtime.
gfx900 is the default target be used right now, although it could be altered via
an option in `mlir-rocm-runner`. Future revisions may consider using ROCm Agent
Enumerator to detect the right target on the system.
Notice AMDGPU Code Object V2 is used in this revision. Future enhancements may
upgrade to AMDGPU Code Object V3.
Bitcode libraries in ROCm-Device-Libs, which implements math routines exposed in
`rocdl` dialect are not yet linked, and is left as a TODO in the logic.
Reviewers: herhut
Subscribers: mgorny, tpr, dexonsmith, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits
Tags: #mlir, #llvm
Differential Revision: https://reviews.llvm.org/D80676
2020-05-21 05:07:49 +08:00
|
|
|
set(MLIR_ROCM_WRAPPER_LIBRARY_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
|
[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype
This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.
- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.
- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).
- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.
Reviewed By: ftynse, mravishankar
Differential Revision: https://reviews.llvm.org/D86108
2020-10-23 22:46:18 +08:00
|
|
|
set(MLIR_SPIRV_WRAPPER_LIBRARY_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
|
2020-02-19 22:11:22 +08:00
|
|
|
set(MLIR_VULKAN_WRAPPER_LIBRARY_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
|
2019-07-04 22:49:52 +08:00
|
|
|
|
2019-03-30 13:10:12 +08:00
|
|
|
configure_lit_site_cfg(
|
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
|
|
|
|
|
MAIN_CONFIG
|
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py
|
|
|
|
|
)
|
|
|
|
|
configure_lit_site_cfg(
|
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.site.cfg.py.in
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg.py
|
|
|
|
|
MAIN_CONFIG
|
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.cfg.py
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set(MLIR_TEST_DEPENDS
|
|
|
|
|
FileCheck count not
|
|
|
|
|
MLIRUnitTests
|
2020-08-05 20:36:16 +08:00
|
|
|
mlir-capi-ir-test
|
2020-11-04 05:38:34 +08:00
|
|
|
mlir-capi-pass-test
|
2019-03-30 13:10:12 +08:00
|
|
|
mlir-cpu-runner
|
2019-05-23 03:13:54 +08:00
|
|
|
mlir-edsc-builder-api-test
|
[mlir][Linalg] Create a tool to generate named Linalg ops from a Tensor Comprehensions-like specification.
Summary:
This revision adds a tool that generates the ODS and C++ implementation for "named" Linalg ops according to the [RFC discussion](https://llvm.discourse.group/t/rfc-declarative-named-ops-in-the-linalg-dialect/745).
While the mechanisms and language aspects are by no means set in stone, this revision allows connecting the pieces end-to-end from a mathematical-like specification.
Some implementation details and short-term decisions taken for the purpose of bootstrapping and that are not set in stone include:
1. using a "[Tensor Comprehension](https://arxiv.org/abs/1802.04730)-inspired" syntax
2. implicit and eager discovery of dims and symbols when parsing
3. using EDSC ops to specify the computation (e.g. std_addf, std_mul_f, ...)
A followup revision will connect this tool to tablegen mechanisms and allow the emission of named Linalg ops that automatically lower to various loop forms and run end to end.
For the following "Tensor Comprehension-inspired" string:
```
def batch_matmul(A: f32(Batch, M, K), B: f32(K, N)) -> (C: f32(Batch, M, N)) {
C(b, m, n) = std_addf<k>(std_mulf(A(b, m, k), B(k, n)));
}
```
With -gen-ods-decl=1, this emits (modulo formatting):
```
def batch_matmulOp : LinalgNamedStructured_Op<"batch_matmul", [
NInputs<2>,
NOutputs<1>,
NamedStructuredOpTraits]> {
let arguments = (ins Variadic<LinalgOperand>:$views);
let results = (outs Variadic<AnyRankedTensor>:$output_tensors);
let extraClassDeclaration = [{
llvm::Optional<SmallVector<StringRef, 8>> referenceIterators();
llvm::Optional<SmallVector<AffineMap, 8>> referenceIndexingMaps();
void regionBuilder(ArrayRef<BlockArgument> args);
}];
let hasFolder = 1;
}
```
With -gen-ods-impl, this emits (modulo formatting):
```
llvm::Optional<SmallVector<StringRef, 8>> batch_matmul::referenceIterators() {
return SmallVector<StringRef, 8>{ getParallelIteratorTypeName(),
getParallelIteratorTypeName(),
getParallelIteratorTypeName(),
getReductionIteratorTypeName() };
}
llvm::Optional<SmallVector<AffineMap, 8>> batch_matmul::referenceIndexingMaps()
{
MLIRContext *context = getContext();
AffineExpr d0, d1, d2, d3;
bindDims(context, d0, d1, d2, d3);
return SmallVector<AffineMap, 8>{
AffineMap::get(4, 0, {d0, d1, d3}),
AffineMap::get(4, 0, {d3, d2}),
AffineMap::get(4, 0, {d0, d1, d2}) };
}
void batch_matmul::regionBuilder(ArrayRef<BlockArgument> args) {
using namespace edsc;
using namespace intrinsics;
ValueHandle _0(args[0]), _1(args[1]), _2(args[2]);
ValueHandle _4 = std_mulf(_0, _1);
ValueHandle _5 = std_addf(_2, _4);
(linalg_yield(ValueRange{ _5 }));
}
```
Differential Revision: https://reviews.llvm.org/D77067
2020-04-11 01:54:08 +08:00
|
|
|
mlir-linalg-ods-gen
|
2019-03-30 13:10:12 +08:00
|
|
|
mlir-opt
|
2020-07-08 07:42:40 +08:00
|
|
|
mlir-reduce
|
2019-05-21 22:22:35 +08:00
|
|
|
mlir-sdbm-api-test
|
2019-03-30 13:10:12 +08:00
|
|
|
mlir-tblgen
|
|
|
|
|
mlir-translate
|
2020-04-10 03:29:06 +08:00
|
|
|
mlir_test_cblas
|
|
|
|
|
mlir_test_cblas_interface
|
2020-02-28 01:58:41 +08:00
|
|
|
mlir_runner_utils
|
2020-02-28 02:45:43 +08:00
|
|
|
mlir_c_runner_utils
|
2020-10-23 03:20:42 +08:00
|
|
|
mlir_async_runtime
|
2019-03-30 13:10:12 +08:00
|
|
|
)
|
|
|
|
|
|
2019-04-03 01:02:07 +08:00
|
|
|
if(LLVM_BUILD_EXAMPLES)
|
|
|
|
|
list(APPEND MLIR_TEST_DEPENDS
|
|
|
|
|
toyc-ch1
|
2019-04-03 04:11:20 +08:00
|
|
|
toyc-ch2
|
2019-04-04 10:16:32 +08:00
|
|
|
toyc-ch3
|
2019-04-05 09:31:31 +08:00
|
|
|
toyc-ch4
|
2019-04-09 14:00:49 +08:00
|
|
|
toyc-ch5
|
2019-10-18 05:21:44 +08:00
|
|
|
toyc-ch6
|
2019-11-08 01:53:27 +08:00
|
|
|
toyc-ch7
|
2019-04-03 01:02:07 +08:00
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-07-04 22:49:52 +08:00
|
|
|
if(MLIR_CUDA_RUNNER_ENABLED)
|
|
|
|
|
list(APPEND MLIR_TEST_DEPENDS
|
|
|
|
|
mlir-cuda-runner
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
[mlir][gpu] Introduce mlir-rocm-runner.
Summary:
`mlir-rocm-runner` is introduced in this commit to execute GPU modules on ROCm
platform. A small wrapper to encapsulate ROCm's HIP runtime API is also inside
the commit.
Due to behavior of ROCm, raw pointers inside memrefs passed to `gpu.launch`
must be modified on the host side to properly capture the pointer values
addressable on the GPU.
LLVM MC is used to assemble AMD GCN ISA coming out from
`ConvertGPUKernelToBlobPass` to binary form, and LLD is used to produce a shared
ELF object which could be loaded by ROCm HIP runtime.
gfx900 is the default target be used right now, although it could be altered via
an option in `mlir-rocm-runner`. Future revisions may consider using ROCm Agent
Enumerator to detect the right target on the system.
Notice AMDGPU Code Object V2 is used in this revision. Future enhancements may
upgrade to AMDGPU Code Object V3.
Bitcode libraries in ROCm-Device-Libs, which implements math routines exposed in
`rocdl` dialect are not yet linked, and is left as a TODO in the logic.
Reviewers: herhut
Subscribers: mgorny, tpr, dexonsmith, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits
Tags: #mlir, #llvm
Differential Revision: https://reviews.llvm.org/D80676
2020-05-21 05:07:49 +08:00
|
|
|
if(MLIR_ROCM_RUNNER_ENABLED)
|
|
|
|
|
list(APPEND MLIR_TEST_DEPENDS
|
|
|
|
|
mlir-rocm-runner
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype
This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.
- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.
- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).
- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.
Reviewed By: ftynse, mravishankar
Differential Revision: https://reviews.llvm.org/D86108
2020-10-23 22:46:18 +08:00
|
|
|
if(MLIR_SPIRV_CPU_RUNNER_ENABLED)
|
|
|
|
|
add_subdirectory(mlir-spirv-cpu-runner)
|
|
|
|
|
list(APPEND MLIR_TEST_DEPENDS
|
|
|
|
|
mlir-spirv-cpu-runner
|
|
|
|
|
mlir_test_spirv_cpu_runner_c_wrappers
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-02-19 22:11:22 +08:00
|
|
|
if(MLIR_VULKAN_RUNNER_ENABLED)
|
|
|
|
|
list(APPEND MLIR_TEST_DEPENDS
|
|
|
|
|
mlir-vulkan-runner
|
|
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
Initial boiler-plate for python bindings.
Summary:
* Native '_mlir' extension module.
* Python mlir/__init__.py trampoline module.
* Lit test that checks a message.
* Uses some cmake configurations that have worked for me in the past but likely needs further elaboration.
Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes
Tags: #mlir
Differential Revision: https://reviews.llvm.org/D83279
2020-07-07 14:05:46 +08:00
|
|
|
if(MLIR_BINDINGS_PYTHON_ENABLED)
|
|
|
|
|
list(APPEND MLIR_TEST_DEPENDS
|
|
|
|
|
MLIRBindingsPythonExtension
|
2020-11-11 02:39:12 +08:00
|
|
|
MLIRTransformsBindingsPythonExtension
|
Initial boiler-plate for python bindings.
Summary:
* Native '_mlir' extension module.
* Python mlir/__init__.py trampoline module.
* Lit test that checks a message.
* Uses some cmake configurations that have worked for me in the past but likely needs further elaboration.
Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes
Tags: #mlir
Differential Revision: https://reviews.llvm.org/D83279
2020-07-07 14:05:46 +08:00
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-03-30 13:10:12 +08:00
|
|
|
add_lit_testsuite(check-mlir "Running the MLIR regression tests"
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}
|
|
|
|
|
DEPENDS ${MLIR_TEST_DEPENDS}
|
|
|
|
|
)
|
|
|
|
|
set_target_properties(check-mlir PROPERTIES FOLDER "Tests")
|
|
|
|
|
|
|
|
|
|
add_lit_testsuites(MLIR ${CMAKE_CURRENT_SOURCE_DIR}
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-16 01:33:13 +08:00
|
|
|
DEPENDS ${MLIR_TEST_DEPENDS}
|
2019-03-30 13:10:12 +08:00
|
|
|
)
|