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.

40 lines
1.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
# 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()
[mlir][linalg] Add script to update the LinalgNamedStructuredOps.yaml. nfc Also adds banners to the files with update instructions. Differential Revision: https://reviews.llvm.org/D108529
2021-08-23 07:54:10 +08:00
configure_file(
update_core_linalg_named_ops.sh.in
${MLIR_TOOLS_DIR}/update_core_linalg_named_ops.sh)