llvm-project/mlir/lib/Bindings/Python/CMakeLists.txt

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

117 lines
3.6 KiB
CMake
Raw Normal View History

include(AddMLIRPythonExtension)
add_custom_target(MLIRBindingsPythonExtension)
[mlir] Add basic support for attributes in ODS-generated Python bindings In ODS, attributes of an operation can be provided as a part of the "arguments" field, together with operands. Such attributes are accepted by the op builder and have accessors generated. Implement similar functionality for ODS-generated op-specific Python bindings: the `__init__` method now accepts arguments together with operands, in the same order as in the ODS `arguments` field; the instance properties are introduced to OpView classes to access the attributes. This initial implementation accepts and returns instances of the corresponding attribute class, and not the underlying values since the mapping scheme of the value types between C++, C and Python is not yet clear. Default-valued attributes are not supported as that would require Python to be able to parse C++ literals. Since attributes in ODS are tightely related to the actual C++ type system, provide a separate Tablegen file with the mapping between ODS storage type for attributes (typically, the underlying C++ attribute class), and the corresponding class name. So far, this might look unnecessary since all names match exactly, but this is not necessarily the cases for non-standard, out-of-tree attributes, which may also be placed in non-default namespaces or Python modules. This also allows out-of-tree users to generate Python bindings without having to modify the bindings generator itself. Storage type was preferred over the Tablegen "def" of the attribute class because ODS essentially encodes attribute _constraints_ rather than classes, e.g. there may be many Tablegen "def"s in the ODS that correspond to the same attribute type with additional constraints The presence of the explicit mapping requires the change in the .td file structure: instead of just calling the bindings generator directly on the main ODS file of the dialect, it becomes necessary to create a new file that includes the main ODS file of the dialect and provides the mapping for attribute types. Arguably, this approach offers better separability of the Python bindings in the build system as the main dialect no longer needs to know that it is being processed by the bindings generator. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D91542
2020-11-16 23:17:03 +08:00
################################################################################
# Copy python source tree.
################################################################################
set(PY_SRC_FILES
mlir/__init__.py
mlir/_dlloader.py
mlir/ir.py
mlir/dialects/__init__.py
mlir/dialects/_linalg.py
mlir/dialects/_builtin.py
mlir/ir.py
mlir/passmanager.py
mlir/transforms/__init__.py
)
add_custom_target(MLIRBindingsPythonSources ALL
DEPENDS ${PY_SRC_FILES}
)
add_dependencies(MLIRBindingsPythonExtension MLIRBindingsPythonSources)
foreach(PY_SRC_FILE ${PY_SRC_FILES})
set(PY_DEST_FILE "${PROJECT_BINARY_DIR}/python/${PY_SRC_FILE}")
add_custom_command(
TARGET MLIRBindingsPythonSources PRE_BUILD
COMMENT "Copying python source ${PY_SRC_FILE} -> ${PY_DEST_FILE}"
DEPENDS "${PY_SRC_FILE}"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different
"${CMAKE_CURRENT_SOURCE_DIR}/${PY_SRC_FILE}" "${PY_DEST_FILE}"
)
endforeach()
################################################################################
# Generate dialect-specific bindings.
################################################################################
add_mlir_dialect_python_bindings(MLIRBindingsPythonBuiltinOps
TD_FILE BuiltinOps.td
DIALECT_NAME builtin)
add_dependencies(MLIRBindingsPythonSources MLIRBindingsPythonBuiltinOps)
add_mlir_dialect_python_bindings(MLIRBindingsPythonLinalgOps
TD_FILE LinalgOps.td
DIALECT_NAME linalg
DEPENDS LinalgOdsGen)
add_dependencies(MLIRBindingsPythonSources MLIRBindingsPythonLinalgOps)
add_mlir_dialect_python_bindings(MLIRBindingsPythonShapeOps
TD_FILE ShapeOps.td
DIALECT_NAME shape)
add_dependencies(MLIRBindingsPythonSources MLIRBindingsPythonShapeOps)
add_mlir_dialect_python_bindings(MLIRBindingsPythonStandardOps
TD_FILE StandardOps.td
DIALECT_NAME std)
add_dependencies(MLIRBindingsPythonSources MLIRBindingsPythonStandardOps)
add_mlir_dialect_python_bindings(MLIRBindingsPythonTensorOps
TD_FILE TensorOps.td
DIALECT_NAME tensor)
add_dependencies(MLIRBindingsPythonSources MLIRBindingsPythonTensorOps)
################################################################################
# Build core python extension
################################################################################
add_mlir_python_extension(MLIRCoreBindingsPythonExtension _mlir
INSTALL_DIR
python
SOURCES
MainModule.cpp
IRModules.cpp
PybindUtils.cpp
Pass.cpp
)
add_dependencies(MLIRBindingsPythonExtension MLIRCoreBindingsPythonExtension)
# Note that we copy from the source tree just like for headers because
# it will not be polluted with py_cache runtime artifacts (from testing and
# such).
install(
DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/mlir
DESTINATION python
COMPONENT MLIRBindingsPythonSources
FILES_MATCHING PATTERN "*.py"
)
if (NOT LLVM_ENABLE_IDE)
add_llvm_install_targets(
install-MLIRBindingsPythonSources
DEPENDS MLIRBindingsPythonSources
COMPONENT MLIRBindingsPythonSources)
endif()
# Dialect sources are generated. Install separately.
# Note that __pycache__ directories may have been left by tests and other
# executions. And __init__.py is handled as a regular source file.
install(
DIRECTORY ${PROJECT_BINARY_DIR}/python/mlir/dialects
DESTINATION python/mlir
COMPONENT MLIRBindingsPythonDialects
FILES_MATCHING PATTERN "*.py"
PATTERN "__pycache__" EXCLUDE
PATTERN "__init__.py" EXCLUDE
)
if (NOT LLVM_ENABLE_IDE)
add_llvm_install_targets(
install-MLIRBindingsPythonDialects
DEPENDS MLIRBindingsPythonSources
COMPONENT MLIRBindingsPythonDialects)
endif()
add_subdirectory(Transforms)