2024-03-08 13:30:34 -08:00
|
|
|
# To silence warning caused by Wundef.
|
|
|
|
|
add_definitions(-DGTEST_NO_LLVM_SUPPORT=0)
|
|
|
|
|
|
2019-03-29 22:10:12 -07:00
|
|
|
function(add_mlir_unittest test_dirname)
|
|
|
|
|
add_unittest(MLIRUnitTests ${test_dirname} ${ARGN})
|
|
|
|
|
endfunction()
|
|
|
|
|
|
2020-07-02 19:18:18 +05:30
|
|
|
add_subdirectory(Analysis)
|
2023-05-24 21:52:05 -07:00
|
|
|
add_subdirectory(Bytecode)
|
Implementation of the root ordering algorithm
This is commit 3 of 4 for the multi-root matching in PDL, discussed in https://llvm.discourse.group/t/rfc-multi-root-pdl-patterns-for-kernel-matching/4148 (topic flagged for review).
We form a graph over the specified roots, provided in `pdl.rewrite`, where two roots are connected by a directed edge if the target root can be connected (via a chain of operations) in the underlying pattern to the source root. We place a restriction that the path connecting the two candidate roots must only contain the nodes in the subgraphs underneath these two roots. The cost of an edge is the smallest number of upward traversals (edges) required to go from the source to the target root, and the connector is a `Value` in the intersection of the two subtrees rooted at the source and target root that results in that smallest number of such upward traversals. Optimal root ordering is then formulated as the problem of finding a spanning arborescence (i.e., a directed spanning tree) of minimal weight.
In order to determine the spanning arborescence (directed spanning tree) of minimum weight, we use the [Edmonds' algorithm](https://en.wikipedia.org/wiki/Edmonds%27_algorithm). The worst-case computational complexity of this algorithm is O(_N_^3) for a single root, where _N_ is the number of specified roots. The `pdl`-to-`pdl_interp` lowering calls this algorithm as a subroutine _N_ times (once for each candidate root), so the overall complexity of root ordering is O(_N_^4). If needed, this complexity could be reduced to O(_N_^3) with a more efficient algorithm. However, note that the underlying implementation is very efficient, and _N_ in our instances tends to be very small (<10). Therefore, we believe that the proposed (asymptotically suboptimal) implementation will suffice for now.
Testing: a unit test of the algorithm
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D108549
2021-11-26 18:08:42 +05:30
|
|
|
add_subdirectory(Conversion)
|
2023-01-23 00:32:07 +00:00
|
|
|
add_subdirectory(Debug)
|
2019-03-29 22:10:12 -07:00
|
|
|
add_subdirectory(Dialect)
|
2021-03-11 14:33:44 +01:00
|
|
|
add_subdirectory(Interfaces)
|
2019-03-29 22:10:12 -07:00
|
|
|
add_subdirectory(IR)
|
[mlir] Allow for attaching external resources to .mlir files
This commit enables support for providing and processing external
resources within MLIR assembly formats. This is a mechanism with which
dialects, and external clients, may attach additional information when
printing IR without that information being encoded in the IR itself.
External resources are not uniqued within the MLIR context, are not
attached directly to any operation, and are solely intended to live and be
processed outside of the immediate IR. There are many potential uses of this
functionality, for example MLIR's pass crash reproducer could utilize this to
attach the pass resource executing when a crash occurs. Other types of
uses may be embedding large amounts of binary data, such as weights in ML
applications, that shouldn't be copied directly into the MLIR context, but
need to be kept adjacent to the IR.
External resources are encoded using a key-value pair nested within a
dictionary anchored by name either on a dialect, or an externally registered
entity. The key is an identifier used to disambiguate the data. The value
may be stored in various limited forms, but general encodings use a string
(human readable) or blob format (binary). Within the textual format, an
example may be of the form:
```mlir
{-#
// The `dialect_resources` section within the file-level metadata
// dictionary is used to contain any dialect resource entries.
dialect_resources: {
// Here is a dictionary anchored on "foo_dialect", which is a dialect
// namespace.
foo_dialect: {
// `some_dialect_resource` is a key to be interpreted by the dialect,
// and used to initialize/configure/etc.
some_dialect_resource: "Some important resource value"
}
},
// The `external_resources` section within the file-level metadata
// dictionary is used to contain any non-dialect resource entries.
external_resources: {
// Here is a dictionary anchored on "mlir_reproducer", which is an
// external entity representing MLIR's crash reproducer functionality.
mlir_reproducer: {
// `pipeline` is an entry that holds a crash reproducer pipeline
// resource.
pipeline: "func.func(canonicalize,cse)"
}
}
```
Differential Revision: https://reviews.llvm.org/D126446
2022-06-28 13:25:24 -07:00
|
|
|
add_subdirectory(Parser)
|
2019-03-29 22:10:12 -07:00
|
|
|
add_subdirectory(Pass)
|
2021-12-27 14:37:47 +05:30
|
|
|
add_subdirectory(Support)
|
2021-03-12 17:39:43 +03:00
|
|
|
add_subdirectory(Rewrite)
|
2019-04-12 05:57:50 -07:00
|
|
|
add_subdirectory(TableGen)
|
2023-08-08 13:33:41 +00:00
|
|
|
add_subdirectory(Target)
|
2024-04-29 10:54:31 -04:00
|
|
|
add_subdirectory(Tools)
|
2021-07-01 20:41:51 +00:00
|
|
|
add_subdirectory(Transforms)
|
2022-01-14 06:57:51 +00:00
|
|
|
|
2022-08-03 15:28:49 +02:00
|
|
|
if(MLIR_ENABLE_EXECUTION_ENGINE)
|
2022-01-14 06:57:51 +00:00
|
|
|
add_subdirectory(ExecutionEngine)
|
|
|
|
|
endif()
|