CINXE.COM

<!doctype html><html lang=en-us><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no"><title>Chapter H: Reproducing Halide Schedule - MLIR</title><meta name=description content="Multi-Level IR Compiler Framework"><meta name=generator content="Hugo 0.119.0"><link href=https://mlir.llvm.org/index.xml rel=alternate type=application/rss+xml><link rel=canonical href=https://mlir.llvm.org/docs/Tutorials/transform/ChH/><link rel=stylesheet href=https://mlir.llvm.org/css/theme.css><script src=https://use.fontawesome.com/releases/v5.0.6/js/all.js></script> <link rel=stylesheet href=https://mlir.llvm.org/css/chroma.min.css><script src=https://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js></script> <script src=https://cdn.jsdelivr.net/npm/jquery.easing@1.4.1/jquery.easing.min.js></script> <script src=https://mlir.llvm.org/js/bundle.js></script> <script type=text/javascript src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> <script type=text/x-mathjax-config> MathJax.Hub.Config({ tex2jax: { inlineMath: [['$', '$'] ], displayMath: [ ['$$','$$'], ["\\[","\\]"] ] } }); </script><link rel=apple-touch-icon sizes=180x180 href="/apple-touch-icon.png?v=1"><link rel=icon type=image/png sizes=32x32 href="/favicon-32x32.png?v=1"><link rel=icon type=image/png sizes=16x16 href="/favicon-16x16.png?v=1"><link rel=manifest href="/site.webmanifest?v=1"><link rel=mask-icon href="/safari-pinned-tab.svg?v=1" color=#3775e0><link rel="shortcut icon" href="/favicon.ico?v=1"><meta name=msapplication-TileColor content="#2d89ef"><meta name=theme-color content="#ffffff"><link rel=icon href=/favicon.svg type=image/svg+xml sizes=any><style>:root{}</style></head><body><div class=container><header><h1><div><img src=https://mlir.llvm.org//mlir-logo.png width=40px align=absmiddle> MLIR</div></h1>Multi-Level IR Compiler Framework</header><div class=global-menu><nav><ul><li class=parent><a href>Community</a><ul class=sub-menu><li class=child><a href=https://llvm.discourse.group/c/mlir/31>Forums</a></li><li class=child><a href=https://discord.gg/xS7Z362>Chat</a></li></ul></li><li><a href=/getting_started/Debugging/>Debugging Tips</a></li><li><a href=/getting_started/Faq/>FAQ</a></li><li class=parent><a href=https://github.com/llvm/llvm-project/tree/main/mlir>Source</a><ul class=sub-menu><li class=child><a href=/doxygen/>Doxygen</a></li><li class=child><a href=https://github.com/llvm/llvm-project/tree/main/mlir>GitHub</a></li></ul></li><li><a href="https://bugs.llvm.org/buglist.cgi?bug_status=__open__&list_id=177877&order=changeddate%20DESC%2Cpriority%2Cbug_severity&product=MLIR&query_format=specific">Bugs</a></li><li><a href=https://github.com/llvm/mlir-www/tree/main/website/static/LogoAssets>Logo Assets</a></li><li><a href=https://www.youtube.com/MLIRCompiler>Youtube Channel</a></li></ul></nav></div><div class=content-container><main><h1>Chapter H: Reproducing Halide Schedule</h1>This chapter demonstrates how a schedule from the <a href=http://halide-lang.org>Halide DSL</a> can be implemented using Transform dialect for structured ops.Note that the IR below is pseudo-code with types removed for brevity. It may also get out of sync with the current syntax. Always refer to the source code in <a href=https://github.com/llvm/llvm-project/tree/main/mlir/test/Examples/transform/ChH>mlir/examples/transform/ChH</a> as the source of truth.<h2 id=channeled-convolution>Channeled Convolution <a class=headline-hash href=#channeled-convolution>¶</a></h2>The Transform dialect provides a substrate for implementing “transformation directive” domain-specific languages (DSLs) in MLIR. Such a DSL, at least in its scheduling part, can target the operations in the Transform dialect that are later applied by the compiler. Sets of transform operations, or even new dialects leveraging the same interfaces and infrastructure, can be added to support a specific DSL for a particular scheduling model. In this chapter, we will revisit the Halide DSL that has (re)popularized separate specification of schedules originally for image processing programs.Two approaches Halide to the Transform dialect are possible:<ul><li>Create a new dialect that corresponds to the computational part of Halide DSL, and define a set of transformations wrapped into Transform dialect operations, that correspond to the scheduling part of the DSL.</li><li>Map the Halide abstractions to the existing MLIR abstractions, for both parts of the DSL.</li></ul>We will consider the latter approach as the computational part of the DSL easily maps to the structured ops in the Linalg dialect. This also gives us the opportunity to discuss how Linalg transformations on the so-called structured operations are similar to or different from the existing transformations.We will consider the 2D channeled convolution example extracted from Halide <a href=https://github.com/halide/Halide/tree/294f80c49bf3bb8582446613c25fcce03b82bcd8/apps/conv_layer>application examples</a>.<div class=highlight><pre tabindex=0 class=chroma><code class=language-cpp data-lang=cpp>// Sizes of the problem. const int N = 5, CI = 128, CO = 128, W = 100, H = 80; // Sized inputs. Note that the order of dimensions is // inverted in Halide with respect to C++, so the last dimension // in the list (N for input, CI for filter) is the least // frequently varying. The C++ equivalent is input[N][H+2][W+2][CI]. Buffer<float, 4> input({CI, W+2, H+2, N}, "input"); Buffer<float, 4> filter({CO, 3, 3, CI}, "filter"); Buffer<float, 1> bias(std::vector<int>{CO}, "bias"); // ... data initialization happens here ... // Declarations of "mathematical functions" for convolution and relu. Func conv("conv"), relu("relu"); // Iterators/subscripts. Var x("x"), y("y"), c("c"), n("n"); // 3D reduction domain (channels and 2 window dimensions), // dimensions are later referred to as r.x, r.y, r.z. RDom r(0, CI, 0, 3, 0, 3); // Core convolution with the result initialized to the bias value. // Note that the order of iterators is inverted in Halide DSL, // i.e. `n` corresponds to the lest frequently-varying (outermost) dimension // here and below. conv(c, x, y, n) = bias(c); conv(c, x, y, n) += filter(c, r.y, r.z, r.x) * input(r.x, x + r.y, y + r.z, n); // ReLU rectification, an elementwise operation. relu(c, x, y, n) = max(0, conv(c, x, y, n)); </code></pre></div>This can be almost directly converted to Linalg dialect operating on tensors, which is conceptually closer to the “mathematical function” abstraction and is where the majority of transformations are available.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>// Bias. Using a named Linalg operation for brevity. %bias_init = tensor.empty() : !toutput %biased = linalg.broadcast ins(%bias : !tbias) outs(%bias_init : !toutput) dimensions = [0, 1, 2] // Convolution proper. While Linalg has named operations for 2D convolutions, // the one in the Halide example has an uncommon order of filter dimensions // and is not supported. It also takes the filter as first argument. This // code recreates it faithfully using the generic form. %convolved = linalg.generic { iterator_types = ["parallel", "parallel", "parallel", "parallel", "reduction", "reduction", "reduction"], indexing_maps = [ affine_map<(n, y, x, c, rz, ry, rx) -> (rx, rz, ry, c)>, affine_map<(n, y, x, c, rz, ry, rx) -> (n, y+rz, x+ry, rx)>, affine_map<(n, y, x, c, rz, ry, rx) -> (n, y, x, c)> ] } ins(%filter, %input: !tfilter, !tinput) outs(%biased : !toutput) { ^bb0(%in: f32, %f: f32, %b: f32): // Note the fastmath attributes that allow operations to be recombined into // %0 = math.fma %in, %f, %b : f32 // later on and to reorder reductions. %m1 = arith.mulf %in, %f {fastmath = #arith.fastmath<fast>} : f32 %0 = arith.addf %b, %m1 {fastmath = #arith.fastmath<fast>} : f32 linalg.yield %0 : f32 } -> !toutput // ReLU is just a max(0, x). %c0 = arith.constant 0.0 : f32 %relued = linalg.generic { iterator_types = ["parallel", "parallel", "parallel", "parallel"], indexing_maps = [ affine_map<(d0, d1, d2, d3) -> ()>, affine_map<(d0, d1, d2, d3) -> (d0, d1, d2, d3)>, affine_map<(d0, d1, d2, d3) -> (d0, d1, d2, d3)> ] } ins(%c0, %convolved : f32, !toutput) outs(%output : !toutput) { ^bb0(%cst: f32, %in: f32, %out: f32): %0 = llvm.intr.maxnum(%cst, %in) : (f32, f32) -> f32 linalg.yield %0 : f32 } -> !toutput </code></pre></div>In Halide, a function such as <code>conv</code> may consist of two parts: a “functional” initialization computation and an in-place update for reductions. This is expressed as two C++ statements in the embedded DSL, but internally is represented in a single object. Linalg doesn’t have such a capability to the initialization and the update are represented as two distinct Linalg operations that are not connected to each other. Furthermore, the <code>x</code>, <code>y</code>, <code>c</code>, <code>n</code> variables in Halide DSL correspond to implicit loops iterating over the corresponding objects, which implies that functions sharing these variables in their definitions also share the corresponding loops. In other words, the loop equivalent of the Halide definition starts in a fully-fused form. The Linalg model is the opposite with each structured operation corresponding to its own loop nest, resulting in a fully-distributed form. This will affect how the schedule is constructed later on.The loop structure for Halide computation resembles the following (adapted from debug dump with <code>HL_DEBUG_CODEGEN=1</code>)<div class=highlight><pre tabindex=0 class=chroma><code class=language-python data-lang=python>for n for y for x for c conv[n, y, x, c] = bias[c] for rz for ry for rx conv[n, y, x, c] += filter[rx, rz, ry, c] * input[n, y+rz, x+ry, rx] relu[n, y, x, c] = max(0, conv[n, y, x, c]) </code></pre></div>The loop structure for the Linalg computation is as follows (obtained by <code>mlir-opt --linalg-generalize-named-ops --empty-tensor-to-alloc-tensor --one-shot-bufferize --convert-linalg-to-loops</code>)<div class=highlight><pre tabindex=0 class=chroma><code class=language-python data-lang=python>for n for y for x for c init[n, y, x, c] = bias[c] for n for y for x for c for rz for ry for rx conv[n, y, x, c] += filter[rx, rz, ry, c] * input[n, y+rz, x+ry, rx] for n for y for x for c relu[n, y, x, c] = max(0, conv[n, y, x, c]) </code></pre></div><h2 id=mapping-halide-scheduling-primitives-to-linalg-structured-transforms>Mapping Halide Scheduling Primitives to Linalg Structured Transforms <a class=headline-hash href=#mapping-halide-scheduling-primitives-to-linalg-structured-transforms>¶</a></h2>The complete Halide schedule listed in the example is as follows<div class=highlight><pre tabindex=0 class=chroma><code class=language-cpp data-lang=cpp>Var co, ci, xo, xi; relu.split(c, co, ci, vec * tile_w) .split(x, xo, xi, tile_h) .reorder(ci, xi, xo, y, n, co) .vectorize(ci, vec) .unroll(ci) .unroll(xi) .parallel(y) .parallel(n) .parallel(co); conv.compute_at(relu, xo) .vectorize(c, vec) .unroll(c) .unroll(x) .unroll(y) .update() .reorder(c, x, y, r.x, r.y, r.z, n) .vectorize(c, vec) .unroll(c) .unroll(x) .unroll(y) .unroll(r.x, 2); </code></pre></div>We will consider only the case without parallelization to avoid the difference in parallel runtimes generated by Halide and used by MLIR. This schedule corresponds to a sequence of loop manipulations, unrolling and vectorization. The following directives are present and can be mapped to transformations on Linalg as described below.<ul><li><code>split</code> decomposes a loop dimension into two immediately nested loops with the inner loop having at most the given number of iterations. This can be understood as loop strip-mining or a degenerate case of tiling a single dimension using any of <code>linalg.tile_</code> transform ops. We will be using <code>transform.structured.tile_using_forall</code> as this kind of loop is best supported by bufferization and can also be turned into a parallel loop later on. Unlike Halide, this doesn’t add new dimensions to the original operation, but rather creates a loop around it and rewrites the operation itself to operate on a subset of the original data.</li><li><code>reorder</code> rearranges the loops arbitrarily. In Linalg representation, loops are implicit and are intended to remain so as long as possible to target microkernels. The order of implicit loops in a <code>linalg.generic</code> operation can be changed by using <code>transform.structured.interchange</code>, but this does not apply to named operations that need to be “generalized” first by calling <code>transform.structured.generalize</code>. However, this can only reorder implicit dimensions and not the explicit loops materialized by tiling operations that can no longer be “folded” into the original operation. Instead, we can leverage this behavior by materializing loops directly in the desired order by “tiling” to size 1.</li><li><code>vectorize</code> indicates that the given dimension should be vectorized with the given factor; if the loop extent is larger than the factor, the loop is effectively split into two parts and the inner one is vectorized. On the contrary, structured Linalg op vectorization applies as a global transformation to all suitable operations at, e.g., a function scope via <code>transform.structured.vectorize_children_and_apply_patterns</code>. It relies on MLIR’s support for multidimensional vectors to directly map multidimensional tensors, which are later decomposed into operations on smaller hardware-compatible vectors during lowering.</li><li><code>unroll</code> performs loop unrolling, fully or up to the given factor. It is equivalent to <code>transform.loop.unroll</code>.</li><li><code>compute_at</code> indicates that the value of the function must be computed within the given loop that will be produced for another function; depending on the relation between loops surrounding functions, this corresponds to either a loop distribution or a producer/consumer fusion. Given that the Linalg representation starts in the fully distributed form, it can be represented as a sequence of <code>transform.structured.fuse_into_containing_op</code> that operates on <code>forall</code> loops materialized by tiling beforehand.</li></ul><h2 id=recreating-the-loop-structure>Recreating the Loop Structure <a class=headline-hash href=#recreating-the-loop-structure>¶</a></h2>The three first transformation directives for <code>relu</code> in the Halide schedule aim at producing the following loop structure.<div class=highlight><pre tabindex=0 class=chroma><code class=language-python data-lang=python>for co for n for y for xo for xi for ci relu[n, y, xo*tile_h + xi, co*tile_w*vec + ci] = ... </code></pre></div>Note that the outer part of the <code>c</code> gets hoisted from all of the surrounding loops. The implicit loop order for the operation is <code>n, y, x, c</code>, so the <code>co</code> loop needs to be materialized first in order to achieve the desired reordering. The remaining dimensions can be materialized as loops in one transformation.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir> // [n y x c] %co, %relu2 = transform.structured.tile_using_forall %relu tile_sizes [0, 0, 0, 64] %n_y_xo, %relu3 = transform.structured.tile_using_forall %relu2 tile_sizes [1, 1, 5, 0] </code></pre></div>This will result in the following loops being created in the IR with the nested elementwise operation operating on a smaller subset of original data via implicit loops.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>scf.forall (%co) in (2) { scf.forall (%n, %y, %xo) in (5, 80, 20) { tensor.extract_slice // Implicit dimensions [ni=0:1, y=0:1, xi=0:5, ci=0:64] %relued = linalg.elemwise_binary { fun = #linalg.binary_fn<max_signed> } // ... scf.forall.in_parallel { tensor.parallel_insert_slice // ... } } } </code></pre></div>The following loop restructuring transformations are <code>compute_at</code> and <code>reorder</code> on the <code>conv</code> function that need to happen before loops are destroyed by unrolling and vectorization. They intend to produce the final desired loop structure.<div class=highlight><pre tabindex=0 class=chroma><code class=language-python data-lang=python>for co for n for y for xo for xi for ci conv[n, y, x*tile_h + xi, co*tile_w*vec + ci] = ... for rz for ry for rx for xi for ci conv[n, y, x*tile_h + xi, co*tile_w*vec + ci] += ... for xi for ci relu[n, y, xo*tile_h + xi, co*tile_w*vec + ci] = ... </code></pre></div>Practically, this corresponds to fusing the convolution initialization and update into the <code>co, n, y, xo</code> loops materialized by tiling earlier. Structured op transformation set supports fusing the producer of a value into its consumer, so fusion happens in two stages:<ul><li>first the main convolution update is fused into ReLU that uses it and has loops materialized;</li><li>then the bias initialization is fused into the convolution+relu loop nest.</li></ul>Each stage consists of two transformations fusing the computational operation into the outer loop, then the inner loop.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>%conv2, %co2 = transform.structured.fuse_into_containing_op %conv into %co %conv3, %n_y_xo2 = transform.structured.fuse_into_containing_op %conv2 into %n_y_xo %bias2, %co3 = transform.structured.fuse_into_containing_op %bias into %co2 %bias3, %n_y_xo3 = transform.structured.fuse_into_containing_op %bias2 into %n_y_xo2 </code></pre></div>To complete the structure, we need to put the <code>rz, ry, rx</code> loops outside the “tile” loops <code>xi, ci</code>. This can be achieved materializing the corresponding loops from the convolution operation. However, these are reduction loops and it wouldn’t be valid to materialize them as intrinsically parallel “forall” loops. Instead, we use the dedicated “reduction tiling” transformation and produce sequential <code>scf.for</code> loops. (<code>scf.forall</code> loops can also express parallel reductions, but the corresponding transformation doesn’t handle reductions along more than one dimension at the moment of writing.)<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>%rz_ry_rx, %red_fill, %conv4, %comb = transform.structured.tile_reduction_using_for %conv3 // n y x c rz ry rx by tile_sizes=[0, 0, 0, 0, 1, 1, 1] </code></pre></div>This transformation materializes the desired loops around the convolution operation. It is also more capable than merely producing (reduction) loops: the transformed code performs <code>tile_size</code> partial reductions of <code>N / tile_size</code> elements, potentially in parallel by changing the dimension kind of the structured operation inside the loop, and then performs a final reduction of these partial results by producing a new “combiner” structured operation after the loops. In our case, <code>tile_size = 1</code> along all dimensions, so the reduction is entirely performed by the generated loops. The combiner structured operation is still produced and adds up the reduction result with the initial value. This changes the order of floating point operations (so would reduction tiling with non-unit size) and may affect the final result due to non-commutativity of these operations, but is explicitly allowed by <code>fastmath</code> flags. Halide also emits LLVM IR with full <code>fastmath</code> flags.Finally, we need to produce innermost loops <code>xi</code> and <code>ci</code> that are still not explicit. As our next step is going to be vectorization along <code>ci</code>, we need to take into account the way it operates on MLIR structured operations: rather than selecting a specific vector size and loop/dimension to vectorize, it directly substitutes multidimensional vector types for tensor types and updates the operations accordingly. Therefore, our tensor type should not become trivial, i.e. size-1, and retain a <code>vector_size</code> sized dimension along the desired axis, <code>ci</code>. This can be achieved by tiling with <code>vector_size</code> as tile size in that dimension:<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>// n y xi ci %1, %c5 = transform.structured.tile_using_forall %conv4 tile_sizes [0, 0, 1, 16] %2, %b4 = transform.structured.tile_using_forall %bias3 tile_sizes [0, 0, 1, 16] %3, %r4 = transform.structured.tile_using_forall %relu3 tile_sizes [0, 0, 1, 16] %4, %c2 = transform.structured.tile_using_forall %comb tile_sizes [0, 0, 1, 16] </code></pre></div>Note that the combiner operation produced by reduction tiling is also tiled here.<h2 id=explicit-loop-unrolling>Explicit Loop Unrolling <a class=headline-hash href=#explicit-loop-unrolling>¶</a></h2>The remaining unhandled loop transformation is unrolling. Specifically, unrolling is requested for the innermost loops that form the 4x5 tile of 16-element vector operations to ensure a contiguous sequence of <code>vfma</code> instructions using 20 512-bit vector registers as accumulators. Unrolling additional loops,, <code>unroll(y)</code> and <code>unroll(r.x, 2)</code>, is requested in the schedule but has no practical effect. That is, the code, and all intermediate representations, produced by Halide with these directives removed is strictly identical to the code with the full schedule. Therefore, we will only unroll the corresponding loops corresponding to <code>xi</code> and <code>ci</code> dimensions that actually get unrolled by Halide.As tiling in the Transform dialect produces handles to the loops materialized by tiling, unrolling those loops is just a matter of chaining the corresponding transformation. Note that the inner loop must be unrolled first as unrolling the outer loop will invalidate the handles to the inner loop.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>transform.loop.unroll %bias_ci {factor = 4} transform.loop.unroll %bias_xi {factor = 5} transform.loop.unroll %conv_ci {factor = 4} transform.loop.unroll %conv_xi {factor = 5} transform.loop.unroll %relu_ci {factor = 4} transform.loop.unroll %relu_xi {factor = 5} transform.loop.unroll %comb_ci {factor = 4} transform.loop.unroll %comb_xi {factor = 5} </code></pre></div><h2 id=vectorization>Vectorization <a class=headline-hash href=#vectorization>¶</a></h2>These transformations produced the desired loop structure and we are now ready to vectorize. Before proceeding it is desirable to simplify the code as tiling and fusion may have produced a lot of operations computing tensor subsets and loop ranges, some of which may be duplicated or excessively complex. Simplification involving canonicalization, common subexpression elimination, loop invariant code motion and various rewrite patterns can be applied directly from the transform dialect. Furthermore, an arbitrary combination of rewrite patterns can be applied in one sweep to a given scope, a functionality that cannot be achieved with conventional compiler passes that apply each group of patterns separately (at least without creating a new pass for each combination of pattern groups).<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>%f00 = transform.structured.match ops{["func.func"]} in %arg0 transform.apply_patterns to %f00 { transform.apply_patterns.canonicalization transform.apply_patterns.linalg.tiling_canonicalization } transform.apply_cse to %f00 %all_loops = transform.structured.match interface{LoopLikeInterface} in %arg0 transform.apply_licm to %all_loops </code></pre></div>One final simplification is necessary to produce good vectorized code. Tiling-by-one as a way of materializing loops produced structured (<code>linalg</code>) operations processing 4D types where only one dimension isn’t unit-sized, e.g., <code>tensor<1x1x1x16xf32></code> where 16 is the vector size corresponding to AVX512, as structured tiling doesn’t modify the rank of the operation in order to preserve the original structure. Even though the core computation is the same, the produced code may end up more complicated than necessary, in particular when decomposing multidimensional vectors into single-dimensional vectors supported by hardware. Such unit dimensions can be explicitly folded away using the corresponding pattern set before vectorization.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>transform.apply_patterns to %f00 { transform.apply_patterns.linalg.fold_unit_extent_dims_via_reshapes } %fv = transform.structured.vectorize_children_and_apply_patterns %f00 </code></pre></div>This produces the desired code performing arithmetic operations on <code>vector<16xf32></code> types that can be easily lowered to AVX512 instructions by the downstream compiler. Vectorization may have created new opportunities for code simplification, in particular combining tensor subsetting and vector slicing operations. Another round of simplification can be applied post vectorization.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>transform.apply_patterns to %fv { transform.apply_patterns.canonicalization transform.apply_patterns.tensor.fold_tensor_subset_ops_into_vector_transfers } transform.apply_cse to %fv transform.structured.hoist_redundant_vector_transfers %fv </code></pre></div><h2 id=lowering-to-llvm-and-the-bufferization-hurdle>Lowering to LLVM and The Bufferization Hurdle <a class=headline-hash href=#lowering-to-llvm-and-the-bufferization-hurdle>¶</a></h2>With the loop restructuring done, the program now needs to be converted to the executable form. The first step in doing so is bufferization, the process that associates a memory buffer with every tensor in the payload IR. MLIR’s one-shot bufferization is directly available as a transform operation.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>%arg1 = transform.bufferization.one_shot_bufferize %arg0 { bufferize_function_boundaries = true, function_boundary_type_conversion = 1 : i32 } </code></pre></div>One-shot bufferization itself does not produce buffer deallocations, which may lead to leaks. So we have to run the buffer deallocation pass pipeline to avoid them. Note that the Transform dialect seamlessly runs named passes and pass pipelines: if desired, one could replace complex <code>--pass-pipeline expressions</code> with operations. Note that we apply the pipeline to functions rather than entire module to avoid running it on the transform IR that is contained in the module.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>%f = transform.structured.match ops{["func.func"]} in %arg1 : (!transform.any_op) -> !transform.any_op transform.apply_registered_pass "buffer-deallocation-pipeline" to %f : (!transform.any_op) -> !transform.any_op </code></pre></div>In this particular case, the transformed IR could be directly bufferized. This is not always the case in general as some operations, in particular <code>tensor.empty</code> may not be bufferizable. Such operations need to be removed before running the bufferization, which can often be achieved by sufficient fusion (as in our case), or by running dedicated transformations <code>transform.bufferization.eliminate_empty_tensors</code> that removes the <code>tensor.empty</code> operations only serving for defining the size of a computation or <code>transform.bufferization.empty_tensor_to_alloc_tensor</code> that materializes a new temporary buffer for empty tensors to be used as local caches.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>// Apply general canonicalization and CSE to each function after // bufferization as new simplification opportunities may have appeared. %fb = transform.structured.match ops{["func.func"]} in %arg1 transform.apply_patterns to %fb { transform.apply_patterns.canonicalization } transform.apply_cse to %fb // Lower complex, multidimensional vector operations into simpler // primitives. This particular selection of the pattern groups corresponds // to vector dialect operations present in the payload IR at this stage. // Many of these groups can be parameterized to use different strategies or // lower-level primitives offering performance trade-offs. In this case, we // are selecting the simplest strategies. transform.apply_patterns to %fb { transform.apply_patterns.vector.lower_contraction lowering_strategy = parallelarith transform.apply_patterns.vector.lower_transfer max_transfer_rank = 1 transform.apply_patterns.vector.lower_transpose lowering_strategy = eltwise transform.apply_patterns.vector.lower_shape_cast } // These patterns apply in a separate sweep to avoid transfer-to-scf // patterns overlap with lower-transfer patterns as they apply to the same // kind of operations. These patterns may produce local allocations to act // as temporary caches deep inside loops, which could lead to catastrophic // performance. Such allocations are moved onto the stack and hoisted from // all the surrounding loops. transform.apply_patterns to %fb { transform.apply_patterns.vector.transfer_to_scf transform.apply_patterns.memref.alloc_to_alloca } transform.bufferization.buffer_loop_hoisting %fb // A final round of cleanups additionally includes patterns to simplify // buffer aliasing operations that may have been introduced during // bufferization and could result in excessively complex address // computation. transform.apply_patterns to %fb { transform.apply_patterns.memref.fold_memref_alias_ops transform.apply_patterns.canonicalization } transform.apply_cse to %fb </code></pre></div>Due to its inter-procedural nature, one-bufferization processes the entire payload module and thus invalidates all previously created handles. Therefore, it is typically a late step in the transformation sequence where precise targeting of transformation is no longer required. The following transformations are typically module- or function-wide rewrites that are often pattern-based lowerings. This part of the sequence can be seen as a pass pipeline specified directly in the transform dialect, with pattern-based lowering passes constructed on-the-fly from named groups of patterns.The resulting IR can be further completely lowered to the LLVM dialect, then to LLVM IR and processed by the LLVM compiler to produce an executable or JITted.The generated code runs in ~420ms on an Intel processor with Skylake microarchitecture clocked at 2.0GHz. Given that the computation performs $<code>5 \cdot 80 \cdot 100 \cdot 128 \cdot (2 \cdot 3 \cdot 3 \cdot 128 + 2) \approx 5.9 * 10^9</code>$ floating point operations, it reaches ~14 GFlops. With 1 FMA unit available, the single-core performance of the test processor is 64 GFlops ($<code>16 \cdot 2 \cdot 2 \cdot 10^9</code>$, where 16 is the vector width), so only 22% of the theoretical peak is achieved.The code produced by Halide runs in ~120ms on the same processor, a 3.5x improvement and 77% of peak. Let us analyze the generated assembly to understand the source of the difference. The main computational effort is expected to happen around floating point multiplications and additions in the convolution. In both cases, the assembly features AVX512 <code>vfma231ps</code> instructions operating on <code>%zmm</code> 512-bit vector registers. In the MLIR-generated code, they are interspersed with memory accesses loading _two _of the <code>fma</code> operands before each operation and leading to increased latency.<div class=highlight><pre tabindex=0 class=chroma><code class=language-asm data-lang=asm>vmovups -192(%r10), %zmm0 vbroadcastss -1536(%rdi,%r9), %zmm1 vmovups 112(%rsp), %zmm2 vfmadd231ps %zmm1, %zmm0, %zmm2 # zmm2 = (zmm0 * zmm1) + zmm2 vmovups %ymm2, 112(%rsp) vextractf64x4 $1, %zmm2, 144(%rsp) // 19 more blocks of either // (a) vmovups,vbroadcast,vfma(z,z),vextract, // (b) vbroadcast,vfma(z,mem),vextract </code></pre></div>The Halide-generated code however features compact blocks of <code>vfma231ps</code> and <code>vbroadcastss</code> loading one of the operands while the other two are resident in registers and loaded before <code>fma</code>.<div class=highlight><pre tabindex=0 class=chroma><code class=language-asm data-lang=asm>vbroadcastss -1536(%rsi,%rbx), %zmm25 vmovups -192(%rdi), %zmm26 vmovups -128(%rdi), %zmm27 vmovups -64(%rdi), %zmm28 vmovups (%rdi), %zmm29 vfmadd231ps %zmm25, %zmm26, %zmm24 # zmm24 = (zmm26 * zmm25) + zmm24 vfmadd231ps %zmm25, %zmm27, %zmm23 # zmm23 = (zmm27 * zmm25) + zmm23 vfmadd231ps %zmm25, %zmm28, %zmm22 # zmm22 = (zmm28 * zmm25) + zmm22 vfmadd231ps %zmm25, %zmm29, %zmm21 # zmm21 = (zmm29 * zmm25) + zmm21 vbroadcastss -1024(%rsi,%rbx), %zmm25 vfmadd231ps %zmm25, %zmm26, %zmm20 # zmm20 = (zmm26 * zmm25) + zmm20 vfmadd231ps %zmm25, %zmm27, %zmm19 # zmm19 = (zmm27 * zmm25) + zmm19 vfmadd231ps %zmm25, %zmm28, %zmm18 # zmm18 = (zmm28 * zmm25) + zmm18 vfmadd231ps %zmm25, %zmm29, %zmm17 # zmm17 = (zmm29 * zmm25) + zmm17 vbroadcastss -512(%rsi,%rbx), %zmm25 // 3 more blocks of 4 vfmadd231 followed by a vbroadcast </code></pre></div>Inspecting the progressive intermediate representations produced by MLIR, one can observe the load(transfer)/fma interspersing at all levels starting after schedule application. The repeated tensor subsetting operations, that are later transformed into vector transfer operations, and vector memory loads, are produced by loop unrolling that was explicitly requested in the schedule! The issue is the single-assignment model of tensors (and vectors) that results in long and complex chains of access and update operations that become so long that the lower-level transformations and the downstream compiler can no longer simplify them. In fact, unrolling loops early in the transformation sequence can lead to all sorts of compiler-performance related problems (including the compiler failing to perform some optimizations due to excessive code length) in the process.It is therefore desirable to perform loop unrolling at a later stage, specifically after bufferization and relevant simplification. However, bufferization invalidates all loop handles including to loops that we are willing to unroll. This hurdle can be overcome by matching the payload IR operations after bufferization to produce new handles. We will first change the kind of loops produced in the schedule from <code>scf.for</code> to <code>scf.forall</code> to have less operations to match by using <code>transform.structured.tile_using_forall</code> instead of <code>transform.structured.tile</code> when tiling with sizes <code>[0, 0, 1, 16]</code>. Then we can match all <code>scf.forall</code> operations in the payload IR and transform them into single-iterator <code>scf.for</code> loops after bufferization.<div class=highlight><pre tabindex=0 class=chroma><code class=language-mlir data-lang=mlir>%foralls = transform.structured.match ops{["scf.forall"]} in %arg1 %xi_bias, %ci_bias = transform.loop.forall_to_for %xi_ci_bias %xi_conv, %ci_conv = transform.loop.forall_to_for %xi_ci_conv %xi_relu, %ci_relu = transform.loop.forall_to_for %xi_ci_relu %xi_comb, %ci_comb = transform.loop.forall_to_for %xi_ci_comb </code></pre></div>We can then move our loop unrolling transformations later in the transformation sequence as desired. Compiling this new version to assembly produces exactly the same core computation around <code>vfmadd231ps</code> as Halide’s version, which only differs slightly in allocated registers. Unsurprisingly, this version runs roughly in 120ms on the same machine.<h2 id=multi-dimensional-vectors-to-the-rescue>Multi-Dimensional Vectors to the Rescue <a class=headline-hash href=#multi-dimensional-vectors-to-the-rescue>¶</a></h2>While we managed to produce similar code to Halide in the previous section, we did so by rematching generated loops after bufferization, which partially defies the purpose of using handles to chain transformations in the Transform dialect. Luckily, this step is not really necessary. It only served as an exercise in producing the desired loop structure.Multidimensional structured operations on vectors are lowered to target-specific vectors by unrolling and splitting. For example, an elementwise arithmetic operation on <code>vector<5x64xf32></code> is replaced with 5 operations on <code>vector<64xf32></code> and additional vector value manipulations to recreate the required type at the MLIR level. Each of these operations is then split into 4 operations on <code>vector<16xf32></code> at the LLVM level where the information about the target vector width becomes available. Collectively, this has exactly the same effect as first materializing the 5x4 loop nest, and then fully unrolling these loops. Therefore, the last stage of tiling, re-matching and unrolling can be removed from the schedule.The resulting assembly has all <code>vbroadcast</code> grouped together before <code>vfmadd231</code> but otherwise has a similar structure. This grouping is due to each multi-dimensional vector operation being “unrolled” separately. When executed, it runs in ~110ms, a slight improvement of 8% over both the previous version and Halide, and reaches ~53.7 GFlop/s or 84% of peak single-core performance. The improvement is largely due to the intermediate representation being shorter and simpler in presence of large-vector operations, which allowed for more aggressive address computation and load placement optimization.The final transformation strategy is checked into the repository at <a href=https://github.com/llvm/llvm-project/tree/main/mlir/test/Examples/transform/ChH/full.mlir>mlir/examples/transform/ChH/full.mlir</a>.<div class=edit-meta> </div><nav class=pagination><a class="nav nav-prev" href=https://mlir.llvm.org/docs/Tutorials/transform/Ch4/ title="Chapter 4: Matching Payload with Transform Operations"> Prev - Chapter 4: Matching Payload with Transform Operations</a> <a class="nav nav-next" href=https://mlir.llvm.org/docs/Tutorials/UnderstandingTheIRStructure/ title="Understanding the IR Structure">Next - Understanding the IR Structure </a></nav><footer>Powered by <a href=https://gohugo.io>Hugo</a>. Theme by <a href=https://themes.gohugo.io/hugo-theme-techdoc/>TechDoc</a>. Designed by <a href=https://github.com/thingsym/hugo-theme-techdoc>Thingsym</a>.</footer></main><div class=sidebar><nav class=slide-menu><ul><li><a href=https://mlir.llvm.org/>Home</a></li><li><a href=https://mlir.llvm.org/users/>Users of MLIR</a></li><li><a href=https://mlir.llvm.org/pubs/>MLIR Related Publications</a></li><li><a href=https://mlir.llvm.org/talks/>Talks</a></li><li><a href=https://mlir.llvm.org/deprecation/>Deprecations & Current Refactoring</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/getting_started/>Getting Started+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/getting_started/ReportingIssues/>Reporting Issues</a></li><li><a href=https://mlir.llvm.org/getting_started/Debugging/>Debugging Tips</a></li><li><a href=https://mlir.llvm.org/getting_started/Faq/>FAQ</a></li><li><a href=https://mlir.llvm.org/getting_started/Contributing/>How to Contribute</a></li><li><a href=https://mlir.llvm.org/getting_started/DeveloperGuide/>Developer Guide</a></li><li><a href=https://mlir.llvm.org/getting_started/openprojects/>Open Projects</a></li><li><a href=https://mlir.llvm.org/getting_started/Glossary/>Glossary</a></li><li><a href=https://mlir.llvm.org/getting_started/TestingGuide/>Testing Guide</a></li></ul></li><li class="parent has-sub-menu"><a href=https://mlir.llvm.org/docs/>Code Documentation-</a><ul class=sub-menu><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Bindings/>Bindings+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Bindings/Python/>MLIR Python Bindings</a></li></ul></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Tools/>Tools+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Tools/MLIRLSP/>MLIR : Language Server Protocol</a></li><li><a href=https://mlir.llvm.org/docs/Tools/mlir-reduce/>MLIR Reduce</a></li><li><a href=https://mlir.llvm.org/docs/Tools/mlir-rewrite/>mlir-rewrite</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/QuantPasses/></a></li><li><a href=https://mlir.llvm.org/docs/ActionTracing/>Action: Tracing and Debugging MLIR-based Compilers</a></li><li><a href=https://mlir.llvm.org/docs/Bufferization/>Bufferization</a></li><li><a href=https://mlir.llvm.org/docs/DataLayout/>Data Layout Modeling</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/DefiningDialects/>Defining Dialects+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/DefiningDialects/Constraints/>Constraints</a></li><li><a href=https://mlir.llvm.org/docs/DefiningDialects/Assembly/>Customizing Assembly Behavior</a></li><li><a href=https://mlir.llvm.org/docs/DefiningDialects/AttributesAndTypes/>Defining Dialect Attributes and Types</a></li><li><a href=https://mlir.llvm.org/docs/DefiningDialects/Operations/>Operation Definition Specification (ODS)</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/Diagnostics/>Diagnostic Infrastructure</a></li><li><a href=https://mlir.llvm.org/docs/DialectConversion/>Dialect Conversion</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Dialects/>Dialects+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Dialects/OpenACCDialect/>'acc' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/Affine/>'affine' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/AMDGPU/>'amdgpu' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/AMX/>'amx' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ArithOps/>'arith' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ArmNeon/>'arm_neon' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ArmSVE/>'arm_sve' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ArmSME/>'ArmSME' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/AsyncDialect/>'async' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/BufferizationOps/>'bufferization' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ControlFlowDialect/>'cf' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ComplexOps/>'complex' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/DLTIDialect/>'dlti' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/EmitC/>'emitc' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/Func/>'func' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/GPU/>'gpu' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/IndexOps/>'index' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/IRDL/>'irdl' Dialect</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Dialects/Linalg/>'linalg' Dialect+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Dialects/Linalg/OpDSL/>Linalg OpDSL</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/Dialects/LLVM/>'llvm' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/MathOps/>'math' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/MemRef/>'memref' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/Mesh/>'mesh' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/MLProgramOps/>'ml_program' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/MPI/>'mpi' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/NVGPU/>'nvgpu' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/NVVMDialect/>'nvvm' Dialect</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Dialects/OpenMPDialect/>'omp' Dialect+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Dialects/OpenMPDialect/ODS/>ODS Documentation</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/Dialects/PDLInterpOps/>'pdl_interp' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/PDLOps/>'pdl' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/PolynomialDialect/>'polynomial' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/PtrOps/>'ptr' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/QuantDialect/>'quant' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ROCDLDialect/>'rocdl' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/SCFDialect/>'scf' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/ShapeDialect/>'shape' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/SparseTensorOps/>'sparse_tensor' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/TensorOps/>'tensor' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/UBOps/>'ub' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/VCIXDialect/>'vcix' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/Vector/>'vector' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/X86Vector/>'x86vector' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/XeGPU/>'xegpu' Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/Builtin/>Builtin Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/MatchOpInterfaces/>OpInterface definitions</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/SPIR-V/>SPIR-V Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/TOSA/>Tensor Operator Set Architecture (TOSA) Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Dialects/Transform/>Transform Dialect</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/Interfaces/>Interfaces</a></li><li><a href=https://mlir.llvm.org/docs/TargetLLVMIR/>LLVM IR Target</a></li><li><a href=https://mlir.llvm.org/docs/BytecodeFormat/>MLIR Bytecode Format</a></li><li><a href=https://mlir.llvm.org/docs/CAPI/>MLIR C API</a></li><li><a href=https://mlir.llvm.org/docs/LangRef/>MLIR Language Reference</a></li><li><a href=https://mlir.llvm.org/docs/ReleaseNotes/>MLIR Release Notes</a></li><li><a href=https://mlir.llvm.org/docs/Canonicalization/>Operation Canonicalization</a></li><li><a href=https://mlir.llvm.org/docs/OwnershipBasedBufferDeallocation/>Ownership-based Buffer Deallocation</a></li><li><a href=https://mlir.llvm.org/docs/PassManagement/>Pass Infrastructure</a></li><li><a href=https://mlir.llvm.org/docs/Passes/>Passes</a></li><li><a href=https://mlir.llvm.org/docs/PatternRewriter/>Pattern Rewriting : Generic DAG-to-DAG Rewriting</a></li><li><a href=https://mlir.llvm.org/docs/PDLL/>PDLL - PDL Language</a></li><li><a href=https://mlir.llvm.org/docs/Quantization/>Quantization</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Rationale/>Rationale+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Rationale/RationaleGenericDAGRewriter/>Generic DAG Rewriter Infrastructure Rationale</a></li><li><a href=https://mlir.llvm.org/docs/Rationale/RationaleLinalgDialect/>Linalg Dialect Rationale: The Case For Compiler-Friendly Custom Operations</a></li><li><a href=https://mlir.llvm.org/docs/Rationale/Rationale/>MLIR Rationale</a></li><li><a href=https://mlir.llvm.org/docs/Rationale/MLIRForGraphAlgorithms/>MLIR: Incremental Application to Graph Algorithms in ML Frameworks</a></li><li><a href=https://mlir.llvm.org/docs/Rationale/RationaleSimplifiedPolyhedralForm/>MLIR: The case for a simplified polyhedral form</a></li><li><a href=https://mlir.llvm.org/docs/Rationale/SideEffectsAndSpeculation/>Side Effects & Speculation</a></li><li><a href=https://mlir.llvm.org/docs/Rationale/UsageOfConst/>Usage of 'const' in MLIR, for core IR types</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/ShapeInference/>Shape Inference</a></li><li><a href=https://mlir.llvm.org/docs/SPIRVToLLVMDialectConversion/>SPIR-V Dialect to LLVM Dialect conversion manual</a></li><li><a href=https://mlir.llvm.org/docs/SymbolsAndSymbolTables/>Symbols and Symbol Tables</a></li><li><a href=https://mlir.llvm.org/docs/DeclarativeRewrites/>Table-driven Declarative Rewrite Rule (DRR)</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Traits/>Traits+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Traits/Broadcastable/>The `Broadcastable` Trait</a></li></ul></li><li class="parent has-sub-menu"><a href=https://mlir.llvm.org/docs/Tutorials/>Tutorials-</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Tutorials/CreatingADialect/>Creating a Dialect</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/QuickstartRewrites/>Quickstart tutorial to adding MLIR graph rewrite</a></li><li class=has-sub-menu><a href=https://mlir.llvm.org/docs/Tutorials/Toy/>Toy Tutorial+</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-1/>Chapter 1: Toy Language and AST</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-2/>Chapter 2: Emitting Basic MLIR</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-3/>Chapter 3: High-level Language-Specific Analysis and Transformation</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-4/>Chapter 4: Enabling Generic Transformation with Interfaces</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-5/>Chapter 5: Partial Lowering to Lower-Level Dialects for Optimization</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-6/>Chapter 6: Lowering to LLVM and CodeGeneration</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/Toy/Ch-7/>Chapter 7: Adding a Composite Type to Toy</a></li></ul></li><li class="parent has-sub-menu"><a href=https://mlir.llvm.org/docs/Tutorials/transform/>Transform Dialect Tutorial-</a><ul class=sub-menu><li><a href=https://mlir.llvm.org/docs/Tutorials/transform/Ch0/>Chapter 0: A Primer on “Structured” Linalg Operations</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/transform/Ch1/>Chapter 1: Combining Existing Transformations</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/transform/Ch2/>Chapter 2: Adding a Simple New Transformation Operation</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/transform/Ch3/>Chapter 3: More than Simple Transform Operations</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/transform/Ch4/>Chapter 4: Matching Payload with Transform Operations</a></li><li class=active><a href=https://mlir.llvm.org/docs/Tutorials/transform/ChH/>Chapter H: Reproducing Halide Schedule</a></li></ul></li><li><a href=https://mlir.llvm.org/docs/Tutorials/UnderstandingTheIRStructure/>Understanding the IR Structure</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/MlirOpt/>Using `mlir-opt`</a></li><li><a href=https://mlir.llvm.org/docs/Tutorials/DataFlowAnalysis/>Writing DataFlow Analyses in MLIR</a></li></ul></li></ul></li></ul></nav><div class=sidebar-footer></div></div></div><a href=# id=backtothetop-fixed class=backtothetop data-backtothetop-duration=600 data-backtothetop-easing=easeOutQuart data-backtothetop-fixed-fadein=1000 data-backtothetop-fixed-fadeout=1000 data-backtothetop-fixed-bottom=10 data-backtothetop-fixed-right=20> </a></div></body></html>