[mlir][transform][tutorial] Make snippets of Ch1 run.

[ingomueller-net]

Summary

The snippets had several problems including mismatching argument names,
stray or missing symbols, and missing updates to changes in transform
ops. I also rewrapped those comments in the snippets that I touchted
that exceeded 80 characters.

[ingomueller-net]

mlir/docs/Tutorials/transform/Ch1.md

194

This took me forever to find :/ Maybe there should be a check whether the op name actually exists or not?

[ftynse]

Thanks! There was also a suggestion in the chat to add a link from the snippet to the test file. Tests are exercised by bots and presumbits so they should be up-to-date.

[ingomueller-net]

(Rebasing to solve build failure.)

mlir/docs/Tutorials/transform/Ch1.md

 
 To check or debug a transform sequence, it is possible to print various entities associated with the transform IR values. For example, we can print the operations associated with the handles:
 
 ```mlir
 transform.sequence failures(propagate) {
 ^bb0(%arg0: !transform.any_op,
      %arg1: !transform.op<"linalg.matmul">,
      %arg2: !transform.op<"linalg.elemwise_binary">):
-  transform.test_print_remark_at_operand %matmul, "matmul"
+  transform.test_print_remark_at_operand %arg1, "matmul"
       : !transform.op<"linalg.matmul">
-  transform.test_print_remark_at_operand %elemwise, "elemwise_binaries"
+  transform.test_print_remark_at_operand %arg2, "elemwise_binaries"
       : !transform.op<"linalg.elemwise_binary">
   transform.yield
 }
 ```
 
 ## Transform Dialect Interpreter
 
 Since we don’t want to recompile the compiler every time we change a transformation, we can use a transform dialect interpreter pass to apply this transformation sequence to the payload IR. As we will see in the next chapter, it is possible to define custom passes or even integrate the transform interpreter into a larger pass. For now, we can use the existing test pass:
 
 
 ```sh
 $ mlir-opt matmul.mlir --pass-pipeline="
     builtin.module(test-transform-dialect-interpreter{
         bind-first-extra-to-ops=linalg.matmul
         bind-second-extra-to-ops=linalg.elemwise_binary})"
 ```
 
 The `matmul.mlir` file contains _both_ the payload IR function _and_ the transform IR sequence nested in the same module. The transform interpreter will find the first top-level transform operation in the root operation of the pass (the module in our case) and apply it to that root operation. In our case, we also asked the interpreter pass to associate the two extra arguments of the top-level sequence with all `linalg.matmul` and `linalg.elemwise_binary` payload operations through the respective pass options. Running this pass results in the expected remarks:
 
 ```sh
 matmul.mlir:7:13: remark: matmul
-  %matmul = linalg.matmul
+  %matmul = linalg.matmul ins(%lhs, %rhs: tensor<512x512xf32>, tensor<512x512xf32>)
             ^
 matmul.mlir:7:13: note: see current operation: %0 = linalg.matmul ins(%arg0, %arg1 : tensor<512x512xf32>, tensor<512x512xf32>) outs(%arg3 : tensor<512x512xf32>) -> tensor<512x512xf32>
 matmul.mlir:10:13: remark: elemwise_binaries
   %biased = linalg.elemwise_binary { fun = #linalg.binary_fn<add> }
             ^
 matmul.mlir:10:13: note: see current operation: %1 = linalg.elemwise_binary {fun = #linalg.binary_fn<add>} ins(%0, %arg2 : tensor<512x512xf32>, tensor<512x512xf32>) outs(%arg3 : tensor<512x512xf32>) -> tensor<512x512xf32>
 matmul.mlir:14:13: remark: elemwise_binaries
   %relued = linalg.elemwise_binary { fun = #linalg.binary_fn<max_signed> }

 
 ```mlir
 transform.sequence failures(propagate) {
 ^bb0(%arg0: !transform.any_op,
      %arg1: !transform.op<"linalg.matmul">,
      %arg2: !transform.op<"linalg.elemwise_binary">):
   // The actual tiling transformation takes tile sizes as attributes.
   %loop, %tiled = transform.structured.tile_to_forall_op %arg1 tile_sizes [4, 32]
-    : (!transform.op<"linalg.matmul") -> (!transform.any_op, !transform.any_op)
+    : (!transform.op<"linalg.matmul">) -> (!transform.any_op, !transform.any_op)
   transform.yield
 }
 ```
 
 The transformation returns two handles, as indicated in its [documentation](https://mlir.llvm.org/docs/Dialects/Transform/#transformstructuredtile_to_forall_op-transformtiletoforallop):
 
 *   A handle to the `scf.forall` “multi-for” loop around tensors.
 *   A handle to `linalg.generic` operating on the subset of the original data.

 ```
 
 However, with the expensive checks enabled in the interpreter, a nice diagnostic is produced:
 
 ```sh
 $ mlir-opt matmul.mlir --pass-pipeline="
     builtin.module(test-transform-dialect-interpreter{
         bind-first-extra-to-ops=linalg.matmul
-        bind-second-extra-to-ops=linalg.elemwise_binary,
+        bind-second-extra-to-ops=linalg.elemwise_binary
         enable-expensive-checks})"
 ```
 
 ```sh
 matmul.mlir:28:3: error: op uses a handle invalidated by a previously executed transform op
   transform.test_print_remark_at_operand %mm, "elemwise_binaries" : !transform.any_op
   ^
 matmul.mlir:26:9: note: handle to invalidated ops
^bb0(%arg0: !transform.any_op,
      %arg2: !transform.op<"linalg.elemwise_binary">):
   // Since the %arg2 handle is associated with both elementwise operations,
   // we need to split it into two handles so we can target only the second
   // elementwise operation.
   %add, %max = transform.split_handle %arg2
       : (!transform.op<"linalg.elemwise_binary">)
       -> (!transform.any_op, !transform.any_op)
 
-  // The actual tiling transformation takes tile sizes as attributes. It produces a
-  // handle to the loop generated during tiling.
-  %loop, %tiled = transform.structured.tile_to_forall_op %max tile_sizes [8, 32]
+  // The actual tiling transformation takes tile sizes as attributes. It
+  // produces a handle to the loop generated during tiling.
+  %loop, %tiled_max =
+      transform.structured.tile_to_forall_op %max tile_sizes [8, 32]
         : (!transform.any_op) -> (!transform.any_op, !transform.any_op)
 
   // We can now fuse the other operations into the loop. Here, we fuse
-  // operations one-by-one. This requires the operation that is being fused
-  // to define the value used within the loop, so the order of such fusions
-  // is important. We could also use "transform.merge_handles" to obtain
-  // a single handle to all operations and give it to `fuse_into_containing_op`
-  // that would take care of the ordering in this case.
-  %add_fused = transform.structured.fuse_into_containing_op %add into %loop
-      : (!transform.any_op, !transform.any_op) -> !transform.any_op
-  %matmul_fused = transform.structured.fuse_into_containing_op %arg1 into %loop
-      : (!transform.op<"linalg.matmul">, !transform.any_op) -> !transform.any_op
+  // operations one by one. This requires the operation that is being fused to
+  // define the value used within the loop, so the order of such fusions is
+  // important. We could also use "transform.merge_handles" to obtain a single
+  // handle to all operations and give it to `fuse_into_containing_op` that
+  // would take care of the ordering in this case.
+  %loop_0, %tiled_add =
+      transform.structured.fuse_into_containing_op %add into %loop
+        : (!transform.any_op, !transform.any_op)
+          -> (!transform.any_op, !transform.any_op)
+  %loop_1, %tiled_matmul =
+      transform.structured.fuse_into_containing_op %arg1 into %loop
+        : (!transform.op<"linalg.matmul">, !transform.any_op)
+          -> (!transform.any_op, !transform.any_op)
 
   transform.yield
 }
-
 ```
 
 This achieves the desired tiling and fusion.
 
 ## More Handle Invalidation
 
 Finally, let us assume there exists an efficient microkernel, or a hardware instruction expressed as an intrinsic function, for a 4x4 matrix multiplication. For this purpose, we need to tile the fused operation to the desired size, and then outline it. The resulting function call can then be replaced with a call to the microkernel.
 
 ```mlir
 transform.sequence failures(propagate) {
 ^bb0(%arg0: !transform.any_op,
      %arg1: !transform.op<"linalg.matmul">,
      %arg2: !transform.op<"linalg.elemwise_binary">):
   // Since the %arg2 handle is associated with both elementwise operations,
   // we need to split it into two handles so we can target only the second
   // elementwise operation.
-  %add, %max = transform.split_handle %arg2 : (!transform.op<"linalg.elemwise_binary">)
+  %add, %max = transform.split_handle %arg2
+      : (!transform.op<"linalg.elemwise_binary">)
         -> (!transform.any_op, !transform.any_op)
 
-  // The actual tiling transformation takes tile sizes as attributes. It produces a
-  // handle to the loop generated during tiling.
+  // The actual tiling transformation takes tile sizes as attributes. It
+  // produces a handle to the loop generated during tiling.
   %loop, %tiled = transform.structured.tile_to_forall_op %max tile_sizes [8, 32]
       : (!transform.any_op) -> (!transform.any_op, !transform.any_op)
 
   // We can now fuse the other operations into the loop. Here, we fuse
-  // operations one-by-one. This requires the operation that is being fused
-  // to define the value used within the loop, so the order of such fusions
-  // is important. We could also use "transform.merge_handles" to obtain
-  // a single handle to all operations and give it to `fuse_into_containing_op`
-  // that would take care of the ordering in this case.
-  %add_fused = transform.structured.fuse_into_containing_op %add into %loop
-      : (!transform.any_op, !transform.any_op) -> !transform.any_op
-  %matmul_fused = transform.structured.fuse_into_containing_op %arg1 into %loop
-      : (!transform.op<"linalg.matmul">, !transform.any_op) -> !transform.any_op
+  // operations one by one. This requires the operation that is being fused to
+  // define the value used within the loop, so the order of such fusions is
+  // important. We could also use "transform.merge_handles" to obtain a single
+  // handle to all operations and give it to `fuse_into_containing_op` that
+  // would take care of the ordering in this case.
+  %add_fused, %loop_0 =
+      transform.structured.fuse_into_containing_op %add into %loop
+        : (!transform.any_op, !transform.any_op)
+          -> (!transform.any_op, !transform.any_op)
+  %matmul_fused, %loop_1 =
+      transform.structured.fuse_into_containing_op %arg1 into %loop
+        : (!transform.op<"linalg.matmul">, !transform.any_op)
+          -> (!transform.any_op, !transform.any_op)
 
   // Tile again to get the desired size. Note that this time this tiles the
   // "add" operation and fuses matmul into the loop, but doesn't affect the
   // "max" operation. This illustrates the precise targeting with the transform
   // dialect. Otherwise, it is difficult to differentiate "add" and "max", both
   // of which having the same kind.
-  %loop_2, %tiled_2 = transform.structured.tile_to_forall_op %add_fused tile_sizes [4, 4]
+  %loop_2, %tiled_2 =
+      transform.structured.tile_to_forall_op %add_fused tile_sizes [4, 4]
         : (!transform.any_op) -> (!transform.any_op, !transform.any_op)
-  %matmul_fused_2 = transform.structured.fuse_into_containing_op %matmul_fused into %loop_2
-      : (!transform.any_op, !transform.any_op) -> !transform.any_op
+  %matmul_fused_2, %loop_3 =
+      transform.structured.fuse_into_containing_op %matmul_fused into %loop_2
+        : (!transform.any_op, !transform.any_op)
+          -> (!transform.any_op, !transform.any_op)
 
   // Since outlining is currently only implemented for region-holding operations
   // such as loops, use tiling to size 1 to materialize the outer loop that is
   // going to be outlined.
-  %outline_target, %_ = transform.structured.tile_to_forall_op %tiled_2 tile_sizes [1]
+  %outline_target, %_ =
+      transform.structured.tile_to_forall_op %tiled_2 tile_sizes [1]
         : (!transform.any_op) -> (!transform.any_op, !transform.any_op)
-  transform.structured.fuse_into_containing_op %matmul_fused_2 into %outline_target
-      : (!transform.any_op, !transform.any_op) -> !transform.any_op
+  transform.structured.fuse_into_containing_op %matmul_fused_2
+      into %outline_target
+        : (!transform.any_op, !transform.any_op)
+          -> (!transform.any_op, !transform.any_op)
   %func, %call = transform.loop.outline %outline_target {func_name = "outlined"}
       : (!transform.any_op) -> (!transform.any_op, !transform.op<"func.call">)
 
   transform.yield
 }
-
 ```
 
 This additional transformation also illustrates handle invalidation for nested operations. The `transform.loop.outline` operation consumes the handle to the loop, which invalidates it and all handles to any operations nested in it, such as `%2`. Attempting to use this handle will cause undefined behavior. (Note that it isn’t strictly necessary for this specific form of the outlining to consume the operand as the implementation only _moves_ the region without recreating the operations, but the author of the transformation chose to invalidate the handle anyway.)
 
 Attempting to access the fusion result after outlining produces the following error
 
 ```sh
 test/Examples/transform/Ch1/invalidation-2.mlir:109:3: error: op uses a handle invalidated by a previously executed transform op