[all-commits] [llvm/llvm-project] 3eb164: Introduced iterative bytecode execution.

Fri Nov 26 04:43:58 PST 2021

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3eb1647af036dc0e8370ed5a8b1ecbb5701f850b
      https://github.com/llvm/llvm-project/commit/3eb1647af036dc0e8370ed5a8b1ecbb5701f850b
  Author: Stanislav Funiak <stano at cerebras.net>
  Date:   2021-11-26 (Fri, 26 Nov 2021)

  Changed paths:
    M mlir/include/mlir/IR/PatternMatch.h
    M mlir/lib/IR/PatternMatch.cpp
    M mlir/lib/Rewrite/ByteCode.cpp
    M mlir/lib/Rewrite/ByteCode.h
    M mlir/test/Rewrite/pdl-bytecode.mlir

  Log Message:
  -----------
  Introduced iterative bytecode execution.

This is commit 2 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).

This commit implements the features needed for the execution of the new operations pdl_interp.get_accepting_ops, pdl_interp.choose_op:
1. The implementation of the generation and execution of the two ops.
2. The addition of Stack of bytecode positions within the ByteCodeExecutor. This is needed because in pdl_interp.choose_op, we iterate over the values returned by pdl_interp.get_accepting_ops until we reach finalize. When we reach finalize, we need to return back to the position marked in the stack.
3. The functionality to extend the lifetime of values that cross the nondeterministic choice. The existing bytecode generator allocates the values to memory positions by representing the liveness of values as a collection of disjoint intervals over the matcher positions. This is akin to register allocation, and substantially reduces the footprint of the bytecode executor. However, because with iterative operation pdl_interp.choose_op, execution "returns" back, so any values whose original liveness cross the nondeterminstic choice must have their lifetime executed until finalize.

Testing: pdl-bytecode.mlir test

Reviewed By: rriddle, Mogball

Differential Revision: https://reviews.llvm.org/D108547

  Commit: 6df7cc7f47d280d550f41fc167bdd75fea726a06
      https://github.com/llvm/llvm-project/commit/6df7cc7f47d280d550f41fc167bdd75fea726a06
  Author: Stanislav Funiak <stano at cerebras.net>
  Date:   2021-11-26 (Fri, 26 Nov 2021)

  Changed paths:
    M mlir/lib/Conversion/PDLToPDLInterp/CMakeLists.txt
    A mlir/lib/Conversion/PDLToPDLInterp/RootOrdering.cpp
    A mlir/lib/Conversion/PDLToPDLInterp/RootOrdering.h
    M mlir/unittests/CMakeLists.txt
    A mlir/unittests/Conversion/CMakeLists.txt
    A mlir/unittests/Conversion/PDLToPDLInterp/CMakeLists.txt
    A mlir/unittests/Conversion/PDLToPDLInterp/RootOrderingTest.cpp

  Log Message:
  -----------
  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

  Commit: a76ee58f3cbcec6e31ff0d25e7d9a89b81a2ccc8
      https://github.com/llvm/llvm-project/commit/a76ee58f3cbcec6e31ff0d25e7d9a89b81a2ccc8
  Author: Stanislav Funiak <stano at cerebras.net>
  Date:   2021-11-26 (Fri, 26 Nov 2021)

  Changed paths:
    M mlir/include/mlir/Dialect/PDL/IR/PDLOps.td
    M mlir/lib/Conversion/PDLToPDLInterp/PDLToPDLInterp.cpp
    M mlir/lib/Conversion/PDLToPDLInterp/Predicate.h
    M mlir/lib/Conversion/PDLToPDLInterp/PredicateTree.cpp
    M mlir/lib/Conversion/PDLToPDLInterp/PredicateTree.h
    M mlir/lib/Dialect/PDL/IR/PDL.cpp
    M mlir/test/Conversion/PDLToPDLInterp/pdl-to-pdl-interp-matcher.mlir
    M mlir/test/Dialect/PDL/invalid.mlir
    M mlir/test/Dialect/PDL/ops.mlir

  Log Message:
  -----------
  Multi-root PDL matching using upward traversals.

This is commit 4 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).

This PR integrates the various components (root ordering algorithm, nondeterministic execution of PDL bytecode) to implement multi-root PDL matching. The main idea is for the pattern to specify mulitple candidate roots. The PDL-to-PDLInterp lowering selects one of these roots and "hangs" the pattern from this root, traversing the edges downwards (from operation to its operands) when possible and upwards (from values to its uses) when needed. The root is selected by invoking the optimal matching multiple times, once for each candidate root, and the connectors are determined form the optimal matching. The costs in the directed graph are equal to the number of upward edges that need to be traversed when connecting the given two candidate roots. It can be shown that, for this choice of the cost function, "hanging" the pattern an inner node is no better than from the optimal root.

The following three main additions were implemented as a part of this PR:
1. OperationPos predicate has been extended to allow tracing the operation accepting a value (the opposite of operation defining a value).
2. Predicate checking if two values are not equal - this is useful to ensure that we do not traverse the edge back downwards after we traversed it upwards.
3. Function for for building the cost graph among the candidate roots.
4. Updated buildPredicateList, building the predicates optimal branching has been determined.

Testing: unit tests (an integration test to follow once the stack of commits has landed)

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D108550

  Commit: d35f1190949963f7b22bd687ed0e27e8636f505d
      https://github.com/llvm/llvm-project/commit/d35f1190949963f7b22bd687ed0e27e8636f505d
  Author: Stanislav Funiak <stano at cerebras.net>
  Date:   2021-11-26 (Fri, 26 Nov 2021)

  Changed paths:
    M mlir/lib/Rewrite/ByteCode.cpp

  Log Message:
  -----------
  Added line numbers to the debug output of PDL bytecode.

This is a small diff that splits out the debug output for PDL bytecode. When running bytecode with debug output on, it is useful to know the line numbers where the PDLIntepr operations are performed. Usually, these are in a single MLIR file, so it's sufficient to print out the line number rather than the entire location (which tends to be quite verbose). This debug output is gated by `LLVM_DEBUG` rather than `#ifndef NDEBUG` to make it easier to test.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D114061

Compare: https://github.com/llvm/llvm-project/compare/08d45e6f4da0...d35f11909499