From: Kai Sasaki Date: Fri, 12 Jun 2020 13:57:35 +0000 (+0200) Subject: [mlir][doc] Fix typos in tutorial chapters X-Git-Tag: llvmorg-12-init~3266 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=ba9e65f9dbb198fb4e85aa5a996bac44beeacdd0;p=platform%2Fupstream%2Fllvm.git [mlir][doc] Fix typos in tutorial chapters Summary: Fix several typos in Toy tutorial chapters. - Chapter 2 - Chapter 5 Differential Revision: https://reviews.llvm.org/D80909 --- diff --git a/mlir/docs/Tutorials/Toy/Ch-2.md b/mlir/docs/Tutorials/Toy/Ch-2.md index 1180a9f..cc5b380 100755 --- a/mlir/docs/Tutorials/Toy/Ch-2.md +++ b/mlir/docs/Tutorials/Toy/Ch-2.md @@ -117,7 +117,7 @@ compiler passes - does not include locations in the output by default. The MLIR is designed to allow most IR elements, such as attributes, operations, and types, to be customized. At the same time, IR -elements can always be reduced to the above fundmental concepts. This +elements can always be reduced to the above fundamental concepts. This allows MLIR to parse, represent, and [round-trip](../../../getting_started/Glossary.md#round-trip) IR for *any* operation. For example, we could place our Toy operation from @@ -134,7 +134,7 @@ func @toy_func(%tensor: tensor<2x3xf64>) -> tensor<3x2xf64> { In the cases of unregistered attributes, operations, and types, MLIR will enforce some structural constraints (SSA, block termination, etc.), but otherwise they are completely opaque. For instance, MLIR -has little information about whether an unregisted operation can +has little information about whether an unregistered operation can operate on particular datatypes, how many operands it can take, or how many results it produces. This flexibility can be useful for bootstrapping purposes, but it is generally advised against in mature @@ -684,10 +684,10 @@ variadic operands, etc. Check out the ## Complete Toy Example We can now generate our "Toy IR". You can build `toyc-ch2` and try yourself on -the above example: `toyc-ch2 test/Examples/Toy/Ch2/codegen.toy -emit=mlir --mlir-print-debuginfo`. We can also check our RoundTrip: `toyc-ch2 -test/Examples/Toy/Ch2/codegen.toy -emit=mlir -mlir-print-debuginfo 2> -codegen.mlir` followed by `toyc-ch2 codegen.mlir -emit=mlir`. You should also +the above example: `toyc-ch2 test/Examples/Toy/Ch2/codegen.toy -emit=mlir +-mlir-print-debuginfo`. We can also check our RoundTrip: `toyc-ch2 +test/Examples/Toy/Ch2/codegen.toy -emit=mlir -mlir-print-debuginfo 2> +codegen.mlir` followed by `toyc-ch2 codegen.mlir -emit=mlir`. You should also use `mlir-tblgen` on the final definition file and study the generated C++ code. At this point, MLIR knows about our Toy dialect and operations. In the diff --git a/mlir/docs/Tutorials/Toy/Ch-5.md b/mlir/docs/Tutorials/Toy/Ch-5.md index ca59da2..0c72736 100644 --- a/mlir/docs/Tutorials/Toy/Ch-5.md +++ b/mlir/docs/Tutorials/Toy/Ch-5.md @@ -76,7 +76,7 @@ void ToyToAffineLoweringPass::runOnFunction() { Above, we first set the toy dialect to illegal, and then the print operation as legal. We could have done this the other way around. -Individual operations always take precendence over the (more generic) dialect +Individual operations always take precedence over the (more generic) dialect definitions, so the order doesn't matter. See `ConversionTarget::getOpInfo` for the details. @@ -336,7 +336,7 @@ func @main() { Here, we can see that a redundant allocation was removed, the two loop nests were fused, and some unnecessary `load`s were removed. You can build `toyc-ch5` -and try yourself: `toyc-ch5 test/Examples/Toy/Ch5/affine-lowering.mlir +and try yourself: `toyc-ch5 test/Examples/Toy/Ch5/affine-lowering.mlir -emit=mlir-affine`. We can also check our optimizations by adding `-opt`. In this chapter we explored some aspects of partial lowering, with the intent to