Fix/clarify parts of MLIR toy tutorial chaper 4.

[matthiaskramm]

Summary

• Let's use "override" when we're just doing standard baseclassing. ("Specialization" makes it sound like template specialization, which this is not.)
• CallInterfaces.td has an include guard, so #ifdef not needed anymore.
• Omit duplicate code in code samples.
• Clarify which algorithm we're talking about.
• Mention that the ShapeInference code is code a snippet that belongs to algorithm discussed in the paragraph above it.
• Add missing definition for createShapeInferencePass.

[matthiaskramm]

Thanks for the quick review! I don't have write access. Any chance you could submit this? (Same question for the other commits you reviewed?)

[rriddle]

In D75260#1896397, @matthiaskramm wrote:

Thanks for the quick review! I don't have write access. Any chance you could submit this? (Same question for the other commits you reviewed?)

Done. Thank you for all of the fixes!

mlir/docs/Tutorials/Toy/Ch-4.md

 transformation is already complex to implement from scratch. Thankfully, MLIR
 provides a generic inliner algorithm that dialects can plug into. All we need to
 do in Toy is to provide the [interfaces](../../Interfaces.md) for the inliner to
 hook into.
 
 The first thing we need to do is to define the constraints on inlining
 operations in the Toy dialect. This information is provided through a
 [dialect interface](../../Interfaces.md#dialect-interfaces). This is essentially
-a class containing a set of virtual hooks for which a dialect may provide a
-specialization. In this case, the interface is `DialectInlinerInterface`.
+a class containing a set of virtual hooks which the dialect can override.
+In this case, the interface is `DialectInlinerInterface`.
 
 ```c++
 /// This class defines the interface for handling inlining with Toy operations.
-/// We simplify inherit from the base interface class and provide a
-/// specialization of the necessary methods.
+/// We simplify inherit from the base interface class and override
+/// the necessary methods.
 struct ToyInlinerInterface : public DialectInlinerInterface {
   using DialectInlinerInterface::DialectInlinerInterface;
 
   /// This hook checks to see if the given operation is legal to inline into the
   /// given region. For Toy this hook can simply return true, as all Toy
   /// operations are inlinable.
   bool isLegalToInline(Operation *, Region *,
                        BlockAndValueMapping &) const final {

 interfaces provide a more refined granularity of information that is specific
 and core to a single operation. The interface that we will be adding here is the
 `CallOpInterface`.
 
 To add this interface we just need to include the definition into our operation
 specification file (`Ops.td`):
 
 ```tablegen
-#ifdef MLIR_CALLINTERFACES
-#else
 include "mlir/Analysis/CallInterfaces.td"
-#endif // MLIR_CALLINTERFACES
 ```
 
 and add it to the traits list of `GenericCallOp`:
 
 ```tablegen
 def GenericCallOp : Toy_Op<"generic_call",
     [DeclareOpInterfaceMethods<CallOpInterface>]> {
   ...

 to have their result shapes inferred.
 
 Similarly to operations, we can also
 [define operation interfaces](../../OpDefinitions.md#operation-interfaces) using
 the operation definition specification (ODS) framework.
 
 The interface is defined by inheriting from `OpInterface`, which takes the name
 to be given to the generated C++ interface class as a template argument. For our
-purposes, we will name the generated class a simpler `ShapeInference`. We also
+purposes, we will simply name the generated class `ShapeInference`. We also
 provide a description for the interface.
 
 ```tablegen
 def ShapeInferenceOpInterface : OpInterface<"ShapeInference"> {
   let description = [{
     Interface to access a registered method to infer the return types for an
     operation that can be used during type inference.
   }];
 }
 ```
 
 Next, we define the interface methods that the operations will need to provide.
 An interface method is comprised of: a description; a C++ return type in string
 form; a method name in string form; and a few optional components, depending on
 the need. See the
 [ODS documentation](../../OpDefinitions.md#operation-interfaces) for more
 information.
 
 ```tablegen
 def ShapeInferenceOpInterface : OpInterface<"ShapeInference"> {
-  let description = [{
-    Interface to access a registered method to infer the return types for an
-    operation that can be used during type inference.
-  }];
+  ...
 
   let methods = [
     InterfaceMethod<"Infer and set the output shape for the current operation.",
                     "void", "inferShapes">
   ];
 }
 ```
 

 At this point, each of the necessary Toy operations provide a mechanism by which
 to infer their output shapes. The ShapeInferencePass is a FunctionPass: it will
 run on each Function in isolation. MLIR also supports general
 [OperationPasses](../../WritingAPass.md#operation-pass) that run on any isolated
 operation (i.e. other function-like operations), but here our module only
 contains functions, so there is no need to generalize to all operations.
 
 Implementing such a pass is done by creating a class inheriting from
-`mlir::FunctionPass` and overriding the `runOnFunction()` method:
+`mlir::FunctionPass` and overriding the `runOnFunction()` method.
 
 ```c++
 class ShapeInferencePass : public mlir::FunctionPass<ShapeInferencePass> {
   void runOnFunction() override {
     FuncOp function = getFunction();
     ...
   }
 };
 ```
 
-The algorithm operates as follows:
+While at it, let's also create a helper method for instantiating the pass:
+
+```c++
+std::unique_ptr<mlir::Pass> mlir::toy::createShapeInferencePass() {
+  return std::make_unique<ShapeInferencePass>();
+}
+```
+
+The shape inference algorithm operates as follows:
 
 1.  Build a worklist containing all the operations that return a dynamically
     shaped tensor: these are the operations that need shape inference.
 2.  Iterate on the worklist:
     -   find an operation to process: the next ready operation in the worklist
         has all of its arguments non-generic,
     -   if no operation is found, break out of the loop,
     -   remove the operation from the worklist,
     -   infer the shape of its output from the argument types.
 3.  If the worklist is empty, the algorithm succeeded.
 
-When processing an operation, we query if it registered the `ShapeInference`
-interface.
+When processing an operation like described, we query if it registered the
+`ShapeInference` interface, using this code snippet:
 
 ```c++
   // Ask the operation to infer its output shapes.
   LLVM_DEBUG(llvm::dbgs() << "Inferring shape for: " << *op << "\n");
 
   /// We check if an operation has a particular interface by casting.
   if (ShapeInference shapeOp = dyn_cast<ShapeInference>(op)) {
     shapeOp.inferShapes();