maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/tools/mlir-linalg-ods-gen/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

72 lines
2.3 KiB
CMake
Raw Normal View History

[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
set(LLVM_LINK_COMPONENTS
Core
Support
)
Implement simple type polymorphism for linalg named ops. * It was decided that this was the end of the line for the existing custom tc parser/generator, and this is the first step to replacing it with a declarative format that maps well to mathy source languages. * One such source language is implemented here: https://github.com/stellaraccident/mlir-linalgpy/blob/main/samples/mm.py * In fact, this is the exact source of the declarative `polymorphic_matmul` in this change. * I am working separately to clean this python implementation up and add it to MLIR (probably as `mlir.tools.linalg_opgen` or equiv). The scope of the python side is greater than just generating named ops: the ops are callable and directly emit `linalg.generic` ops fully dynamically, and this is intended to be a feature for frontends like npcomp to define custom linear algebra ops at runtime. * There is more work required to handle full type polymorphism, especially with respect to integer formulations, since they require more specificity wrt types. * Followups to this change will bring the new generator to feature parity with the current one and delete the current. Roughly, this involves adding support for interface declarations and attribute symbol bindings. Differential Revision: https://reviews.llvm.org/D97135
2021-02-21 14:46:27 +08:00
set(LLVM_OPTIONAL_SOURCES
mlir-linalg-ods-gen.cpp
mlir-linalg-ods-yaml-gen.cpp
)
# Original mlir-linalg-ods-gen (to be replaced).
Revert "[RFC] Factor out repetitive cmake patterns for llvm-style projects" This reverts commit e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca. There are issues with macros generating macros without an obvious simple fix so I'm going to revert this and try something different.
2020-10-05 06:17:34 +08:00
add_llvm_tool(mlir-linalg-ods-gen
[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.cpp
)
llvm_update_compile_flags(mlir-linalg-ods-gen)
target_link_libraries(mlir-linalg-ods-gen PRIVATE
MLIRSupport
Tweak `mlir-linalg-ods-gen` library dependency: only MLIRIR is needed, not the entire parser (NFC)
2020-09-03 07:57:47 +08:00
MLIRIR
[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] Fix cross-compilation (Linalg ODS gen) Use cross-compilation approach for `mlir-linalg-ods-gen` application similar to TblGen tools. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D94598
2021-01-18 18:54:06 +08:00
fix linalg ods gen cross compiling like other gen executables Signed-off-by: daquexian <daquexian566@gmail.com> Reviewed By: vinograd47 Differential Revision: https://reviews.llvm.org/D96645
2021-02-14 01:15:47 +08:00
set(MLIR_LINALG_ODS_GEN mlir-linalg-ods-gen CACHE
STRING "Native mlir-linalg-ods-gen executable. Saves building one when cross-compiling.")
set(MLIR_LINALG_ODS_GEN_EXE ${MLIR_LINALG_ODS_GEN} PARENT_SCOPE)
[mlir] Fix cross-compilation (Linalg ODS gen) Use cross-compilation approach for `mlir-linalg-ods-gen` application similar to TblGen tools. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D94598
2021-01-18 18:54:06 +08:00
set(MLIR_LINALG_ODS_GEN_TARGET mlir-linalg-ods-gen PARENT_SCOPE)
if(LLVM_USE_HOST_TOOLS)
[mlir][CMAKE] Fix cross-compilation build Use `MLIR_LINALG_ODS_GEN` and `MLIR_LINALG_ODS_YAML_GEN` variables instead of `MLIR_LINALG_ODS_GEN_EXE` and `MLIR_LINALG_ODS_YAML_GEN_EXE`. The former are defined in PARENT SCOPE only, so the `if` condition is never evaluates to `TRUE`. The logic should be the following (taken from tblgen part): 1. `TOOL_NAME` - CACHE variable (default equal to target name). User can override it to actual executable path. 2. `TOOL_NAME_EXE` - internal variable, initialized to `${TOOL_NAME}` first. In case of cross-compilation (`LLVM_USE_HOST_TOOLS == TRUE`) if user didn't set own path to native executable via `TOOL_NAME` variable, CMake will create separate targets to build native tool and will override `TOOL_NAME_EXE` to the executable produced by this target. 3. `TOOL_NAME_TARGET` - internal variable, which points to tool target name. If the native tool is built as described above, it will point to the target correspondant to that native tool. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D98025
2021-03-05 01:24:25 +08:00
if (${MLIR_LINALG_ODS_GEN} STREQUAL "mlir-linalg-ods-gen")
fix linalg ods gen cross compiling like other gen executables Signed-off-by: daquexian <daquexian566@gmail.com> Reviewed By: vinograd47 Differential Revision: https://reviews.llvm.org/D96645
2021-02-14 01:15:47 +08:00
build_native_tool(mlir-linalg-ods-gen MLIR_LINALG_ODS_GEN_EXE DEPENDS mlir-linalg-ods-gen)
set(MLIR_LINALG_ODS_GEN_EXE ${MLIR_LINALG_ODS_GEN_EXE} PARENT_SCOPE)
[mlir] Fix cross-compilation (Linalg ODS gen) Use cross-compilation approach for `mlir-linalg-ods-gen` application similar to TblGen tools. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D94598
2021-01-18 18:54:06 +08:00
fix linalg ods gen cross compiling like other gen executables Signed-off-by: daquexian <daquexian566@gmail.com> Reviewed By: vinograd47 Differential Revision: https://reviews.llvm.org/D96645
2021-02-14 01:15:47 +08:00
add_custom_target(mlir-linalg-ods-gen-host DEPENDS ${MLIR_LINALG_ODS_GEN_EXE})
set(MLIR_LINALG_ODS_GEN_TARGET mlir-linalg-ods-gen-host DEPENDS PARENT_SCOPE)
[mlir] Fix cross-compilation (Linalg ODS gen) Use cross-compilation approach for `mlir-linalg-ods-gen` application similar to TblGen tools. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D94598
2021-01-18 18:54:06 +08:00
fix linalg ods gen cross compiling like other gen executables Signed-off-by: daquexian <daquexian566@gmail.com> Reviewed By: vinograd47 Differential Revision: https://reviews.llvm.org/D96645
2021-02-14 01:15:47 +08:00
if(NOT LLVM_BUILD_UTILS)
set_target_properties(mlir-linalg-ods-gen PROPERTIES EXCLUDE_FROM_ALL ON)
endif()
[mlir] Fix cross-compilation (Linalg ODS gen) Use cross-compilation approach for `mlir-linalg-ods-gen` application similar to TblGen tools. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D94598
2021-01-18 18:54:06 +08:00
endif()
endif()
Implement simple type polymorphism for linalg named ops. * It was decided that this was the end of the line for the existing custom tc parser/generator, and this is the first step to replacing it with a declarative format that maps well to mathy source languages. * One such source language is implemented here: https://github.com/stellaraccident/mlir-linalgpy/blob/main/samples/mm.py * In fact, this is the exact source of the declarative `polymorphic_matmul` in this change. * I am working separately to clean this python implementation up and add it to MLIR (probably as `mlir.tools.linalg_opgen` or equiv). The scope of the python side is greater than just generating named ops: the ops are callable and directly emit `linalg.generic` ops fully dynamically, and this is intended to be a feature for frontends like npcomp to define custom linear algebra ops at runtime. * There is more work required to handle full type polymorphism, especially with respect to integer formulations, since they require more specificity wrt types. * Followups to this change will bring the new generator to feature parity with the current one and delete the current. Roughly, this involves adding support for interface declarations and attribute symbol bindings. Differential Revision: https://reviews.llvm.org/D97135
2021-02-21 14:46:27 +08:00
# New mlir-linalg-ods-yaml-gen.
add_llvm_tool(mlir-linalg-ods-yaml-gen
mlir-linalg-ods-yaml-gen.cpp
)
llvm_update_compile_flags(mlir-linalg-ods-yaml-gen)
target_link_libraries(mlir-linalg-ods-yaml-gen PRIVATE
MLIRIR
MLIRSupport
MLIRParser
)
set(MLIR_LINALG_ODS_YAML_GEN mlir-linalg-ods-yaml-gen CACHE
STRING "Native mlir-linalg-ods-yaml-gen executable. Saves building one when cross-compiling.")
set(MLIR_LINALG_ODS_YAML_GEN_EXE ${MLIR_LINALG_ODS_YAML_GEN} PARENT_SCOPE)
set(MLIR_LINALG_ODS_YAML_GEN_TARGET mlir-linalg-ods-yaml-gen PARENT_SCOPE)
if(LLVM_USE_HOST_TOOLS)
[mlir][CMAKE] Fix cross-compilation build Use `MLIR_LINALG_ODS_GEN` and `MLIR_LINALG_ODS_YAML_GEN` variables instead of `MLIR_LINALG_ODS_GEN_EXE` and `MLIR_LINALG_ODS_YAML_GEN_EXE`. The former are defined in PARENT SCOPE only, so the `if` condition is never evaluates to `TRUE`. The logic should be the following (taken from tblgen part): 1. `TOOL_NAME` - CACHE variable (default equal to target name). User can override it to actual executable path. 2. `TOOL_NAME_EXE` - internal variable, initialized to `${TOOL_NAME}` first. In case of cross-compilation (`LLVM_USE_HOST_TOOLS == TRUE`) if user didn't set own path to native executable via `TOOL_NAME` variable, CMake will create separate targets to build native tool and will override `TOOL_NAME_EXE` to the executable produced by this target. 3. `TOOL_NAME_TARGET` - internal variable, which points to tool target name. If the native tool is built as described above, it will point to the target correspondant to that native tool. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D98025
2021-03-05 01:24:25 +08:00
if (${MLIR_LINALG_ODS_YAML_GEN} STREQUAL "mlir-linalg-ods-yaml-gen")
build_native_tool(mlir-linalg-ods-yaml-gen MLIR_LINALG_ODS_YAML_GEN_EXE DEPENDS mlir-linalg-ods-yaml-gen)
set(MLIR_LINALG_ODS_YAML_GEN_EXE ${MLIR_LINALG_ODS_YAML_GEN_EXE} PARENT_SCOPE)
Implement simple type polymorphism for linalg named ops. * It was decided that this was the end of the line for the existing custom tc parser/generator, and this is the first step to replacing it with a declarative format that maps well to mathy source languages. * One such source language is implemented here: https://github.com/stellaraccident/mlir-linalgpy/blob/main/samples/mm.py * In fact, this is the exact source of the declarative `polymorphic_matmul` in this change. * I am working separately to clean this python implementation up and add it to MLIR (probably as `mlir.tools.linalg_opgen` or equiv). The scope of the python side is greater than just generating named ops: the ops are callable and directly emit `linalg.generic` ops fully dynamically, and this is intended to be a feature for frontends like npcomp to define custom linear algebra ops at runtime. * There is more work required to handle full type polymorphism, especially with respect to integer formulations, since they require more specificity wrt types. * Followups to this change will bring the new generator to feature parity with the current one and delete the current. Roughly, this involves adding support for interface declarations and attribute symbol bindings. Differential Revision: https://reviews.llvm.org/D97135
2021-02-21 14:46:27 +08:00
[mlir][CMAKE] Fix cross-compilation build Use `MLIR_LINALG_ODS_GEN` and `MLIR_LINALG_ODS_YAML_GEN` variables instead of `MLIR_LINALG_ODS_GEN_EXE` and `MLIR_LINALG_ODS_YAML_GEN_EXE`. The former are defined in PARENT SCOPE only, so the `if` condition is never evaluates to `TRUE`. The logic should be the following (taken from tblgen part): 1. `TOOL_NAME` - CACHE variable (default equal to target name). User can override it to actual executable path. 2. `TOOL_NAME_EXE` - internal variable, initialized to `${TOOL_NAME}` first. In case of cross-compilation (`LLVM_USE_HOST_TOOLS == TRUE`) if user didn't set own path to native executable via `TOOL_NAME` variable, CMake will create separate targets to build native tool and will override `TOOL_NAME_EXE` to the executable produced by this target. 3. `TOOL_NAME_TARGET` - internal variable, which points to tool target name. If the native tool is built as described above, it will point to the target correspondant to that native tool. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D98025
2021-03-05 01:24:25 +08:00
add_custom_target(mlir-linalg-ods-yaml-gen-host DEPENDS ${MLIR_LINALG_ODS_YAML_GEN_EXE})
set(MLIR_LINALG_ODS_YAML_GEN_TARGET mlir-linalg-ods-yaml-gen-host DEPENDS PARENT_SCOPE)
Implement simple type polymorphism for linalg named ops. * It was decided that this was the end of the line for the existing custom tc parser/generator, and this is the first step to replacing it with a declarative format that maps well to mathy source languages. * One such source language is implemented here: https://github.com/stellaraccident/mlir-linalgpy/blob/main/samples/mm.py * In fact, this is the exact source of the declarative `polymorphic_matmul` in this change. * I am working separately to clean this python implementation up and add it to MLIR (probably as `mlir.tools.linalg_opgen` or equiv). The scope of the python side is greater than just generating named ops: the ops are callable and directly emit `linalg.generic` ops fully dynamically, and this is intended to be a feature for frontends like npcomp to define custom linear algebra ops at runtime. * There is more work required to handle full type polymorphism, especially with respect to integer formulations, since they require more specificity wrt types. * Followups to this change will bring the new generator to feature parity with the current one and delete the current. Roughly, this involves adding support for interface declarations and attribute symbol bindings. Differential Revision: https://reviews.llvm.org/D97135
2021-02-21 14:46:27 +08:00
[mlir][CMAKE] Fix cross-compilation build Use `MLIR_LINALG_ODS_GEN` and `MLIR_LINALG_ODS_YAML_GEN` variables instead of `MLIR_LINALG_ODS_GEN_EXE` and `MLIR_LINALG_ODS_YAML_GEN_EXE`. The former are defined in PARENT SCOPE only, so the `if` condition is never evaluates to `TRUE`. The logic should be the following (taken from tblgen part): 1. `TOOL_NAME` - CACHE variable (default equal to target name). User can override it to actual executable path. 2. `TOOL_NAME_EXE` - internal variable, initialized to `${TOOL_NAME}` first. In case of cross-compilation (`LLVM_USE_HOST_TOOLS == TRUE`) if user didn't set own path to native executable via `TOOL_NAME` variable, CMake will create separate targets to build native tool and will override `TOOL_NAME_EXE` to the executable produced by this target. 3. `TOOL_NAME_TARGET` - internal variable, which points to tool target name. If the native tool is built as described above, it will point to the target correspondant to that native tool. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D98025
2021-03-05 01:24:25 +08:00
if(NOT LLVM_BUILD_UTILS)
set_target_properties(mlir-linalg-ods-yaml-gen PROPERTIES EXCLUDE_FROM_ALL ON)
endif()
Implement simple type polymorphism for linalg named ops. * It was decided that this was the end of the line for the existing custom tc parser/generator, and this is the first step to replacing it with a declarative format that maps well to mathy source languages. * One such source language is implemented here: https://github.com/stellaraccident/mlir-linalgpy/blob/main/samples/mm.py * In fact, this is the exact source of the declarative `polymorphic_matmul` in this change. * I am working separately to clean this python implementation up and add it to MLIR (probably as `mlir.tools.linalg_opgen` or equiv). The scope of the python side is greater than just generating named ops: the ops are callable and directly emit `linalg.generic` ops fully dynamically, and this is intended to be a feature for frontends like npcomp to define custom linear algebra ops at runtime. * There is more work required to handle full type polymorphism, especially with respect to integer formulations, since they require more specificity wrt types. * Followups to this change will bring the new generator to feature parity with the current one and delete the current. Roughly, this involves adding support for interface declarations and attribute symbol bindings. Differential Revision: https://reviews.llvm.org/D97135
2021-02-21 14:46:27 +08:00
endif()
endif()