[mlir] Fix typos and broken links in LangRef

[fdeazeve]

Summary

Many pages have had their titles renamed over time,
causing broken links to spread throughout the documentation.

[fdeazeve]

@ftynse would you be able to merge this for me? I don't have write access to the repo.

mlir/docs/LangRef.md

 
 MLIR is fundamentally based on a graph-like data structure of nodes, called
 *Operations*, and edges, called *Values*. Each Value is the result of exactly
 one Operation or Block Argument, and has a *Value Type* defined by the [type
 system](#type-system).  [Operations](#operations) are contained in
 [Blocks](#blocks) and Blocks are contained in [Regions](#regions). Operations
 are also ordered within their containing block and Blocks are ordered in their
 containing region, although this order may or may not be semantically
-meaningful in a given [kind of region](Interfaces.md#regionkindinterface)).
+meaningful in a given [kind of region](Interfaces.md#regionkindinterfaces)).
 Operations may also contain regions, enabling hierarchical structures to be
 represented.
 
 Operations can represent many different concepts, from higher-level concepts
 like function definitions, function calls, buffer allocations, view or slices
 of buffers, and process creation, to lower-level concepts like
 target-independent arithmetic, target-specific instructions, configuration
 registers, and logic gates. These different concepts are represented by
 different operations in MLIR and the set of operations usable in MLIR can be
 arbitrarily extended.
 
 MLIR also provides an extensible framework for transformations on operations,
 using familiar concepts of compiler [Passes](Passes.md). Enabling an arbitrary
 set of passes on an arbitrary set of operations results in a significant
 scaling challenge, since each transformation must potentially take into
 account the semantics of any operation. MLIR addresses this complexity by
 allowing operation semantics to be described abstractly using
 [Traits](Traits.md) and [Interfaces](Interfaces.md), enabling transformations
 to operate on operations more generically.  Traits often describe verification
 constraints on valid IR, enabling complex invariants to be captured and
-checked. (see
-[docs/Tutorials/Toy/Ch-2/#op-vs-operation-using-mlir-operations])
+checked. (see [Op vs
+Operation](docs/Tutorials/Toy/Ch-2/#op-vs-operation-using-mlir-operations))
 
 One obvious application of MLIR is to represent an
 [SSA-based](https://en.wikipedia.org/wiki/Static_single_assignment_form) IR,
 like the LLVM core IR, with appropriate choice of Operation Types to define
 [Modules](#module), [Functions](#functions), Branches, Allocations, and
 verification constraints to ensure the SSA Dominance property. MLIR includes a
 'standard' dialect which defines just such structures. However, MLIR is
 intended to be general enough to represent other compiler-like data

 value-id-and-type-list ::= value-id-and-type (`,` value-id-and-type)*
 
 block-arg-list ::= `(` value-id-and-type-list? `)`
 ```
 
 A *Block* is an ordered list of operations, concluding with a single
 [terminator operation](#terminator-operations). In [SSACFG
 regions](#control-flow-and-ssacfg-regions), each block represents a compiler
-[basic block] (https://en.wikipedia.org/wiki/Basic_block) where instructions
+[basic block](https://en.wikipedia.org/wiki/Basic_block) where instructions
 inside the block are executed in order and terminator operations implement
 control flow branches between basic blocks.
 
 Blocks in MLIR take a list of block arguments, notated in a function-like
 way. Block arguments are bound to values specified by the semantics of
 individual operations. Block arguments of the entry block of a region are also
 arguments to the region and the values bound to these arguments are determined
 by the semantics of the containing operation. Block arguments of other blocks

 
 A region is an ordered list of MLIR [Blocks](#blocks). The semantics within a
 region is not imposed by the IR. Instead, the containing operation defines the
 semantics of the regions it contains. MLIR currently defines two kinds of
 regions: [SSACFG regions](#control-flow-and-ssacfg-regions), which describe
 control flow between blocks, and [Graph regions](#graph-regions), which do not
 require control flow between block. The kinds of regions within an operation
 are described using the
-[RegionKindInterface](Interfaces.md#regionkindinterface).
+[RegionKindInterface](Interfaces.md#regionkindinterfaces).
 
 Regions do not have a name or an address, only the blocks contained in a
 region do. Regions must be contained within operations and have no type or
 attributes. The first block in the region is a special block called the 'entry
 block'. The arguments to the entry block are also the arguments of the region
 itself. The entry block cannot be listed as a successor of any other
 block. The syntax for a region is as follows:
 

 can be used by an operation which has a parent in the same region, if and only
 if the parent could use the value. A value defined by an argument to a region
 can always be used by any operation deeply contained in the region. A value
 defined in a region can never be used outside of the region.
 
 ### Control Flow and SSACFG Regions
 
 In MLIR, control flow semantics of a region is indicated by
-[RegionKind::SSACFG](Interfaces.md#regionkindinterface).  Informally, these
+[RegionKind::SSACFG](Interfaces.md#regionkindinterfaces).  Informally, these
 regions support semantics where operations in a region 'execute
 sequentially'. Before an operation executes, its operands have well-defined
 values. After an operation executes, the operands have the same values and
 results also have well-defined values. After an operation executes, the next
 operation in the block executes until the operation is the terminator operation
 at the end of a block, in which case some other operation will execute. The
 determination of the next instruction to execute is the 'passing of control
 flow'.

 operation to define its semantics. Note that if an operation triggers
 asynchronous execution of the region, it is under the responsibility of the
 operation caller to wait for the region to be executed guaranteeing that any
 directly used values remain live.
 
 ### Graph Regions
 
 In MLIR, graph-like semantics in a region is indicated by
-[RegionKind::Graph](Interfaces.md#regionkindinterface). Graph regions are
+[RegionKind::Graph](Interfaces.md#regionkindinterfaces). Graph regions are
 appropriate for concurrent semantics without control flow, or for modeling
 generic directed graph data structures. Graph regions are appropriate for
 representing cyclic relationships between coupled values where there is no
 fundamental order to the relationships. For instance, operations in a graph
 region may represent independent threads of control with values representing
 streams of data. As usual in MLIR, the particular semantics of a region is
 completely determined by its containing operation. Graph regions may only
 contain a single basic block (the entry block).

 // MLIR functions can return multiple values.
 function-result-type ::= type-list-parens
                        | non-function-type
 
 function-type ::= type-list-parens `->` function-result-type
 ```
 
 MLIR supports first-class functions: for example, the
-[`constant` operation](Dialects/Standard.md#constant-operation) produces the
+[`constant` operation](Dialects/Standard.md#stdconstant-constantop) produces the
 address of a function as a value. This value may be passed to and
 returned from functions, merged across control flow boundaries with
 [block arguments](#blocks), and called with the
 [`call_indirect` operation](Dialects/Standard.md#call-indirect-operation).
 
 Function types are also used to indicate the arguments and results of
 [operations](#operations).
 
 #### Index Type
 
 Syntax:
 
 ```
 // Target word-sized integer.
 index-type ::= `index`
 ```
 
 The `index` type is a signless integer whose size is equal to the natural
-machine word of the target ([rationale](Rationale/Rationale.md#signless-types)) and is
-used by the affine constructs in MLIR. Unlike fixed-size integers, it cannot be
-used as an element of vector, tensor or memref type
-([rationale](Rationale/Rationale.md#index-type-disallowed-in-vectortensormemref-types)).
+machine word of the target
+([rationale](Rationale/Rationale.md#integer-signedness-semantics)) and is used
+by the affine constructs in MLIR. Unlike fixed-size integers, it cannot be used
+as an element of vector
+([rationale](Rationale/Rationale.md#index-type-disallowed-in-vector-types)).
 
 **Rationale:** integers of platform-specific bit widths are practical to express
 sizes, dimensionalities and subscripts.
 
 #### Integer Type
 
 Syntax:
 

 dialect-attribute-entry ::= dialect-namespace `.` bare-id `=` attribute-value
 dependent-attribute-entry ::= dependent-attribute-name `=` attribute-value
 dependent-attribute-name ::= ((letter|[_]) (letter|digit|[_$])*)
                            | string-literal
 ```
 
 Attributes are the mechanism for specifying constant data on operations in
 places where a variable is never allowed - e.g. the index of a
-[`dim` operation](Dialects/Standard.md#dim-operation), or the stride of a
+[`dim` operation](Dialects/Standard.md#stddim-dimop), or the stride of a
 convolution. They consist of a name and a concrete attribute value. The set of
 expected attributes, their structure, and their interpretation are all
 contextually dependent on what they are attached to.
 
 There are two main classes of attributes: dependent and dialect. Dependent
 attributes derive their structure and meaning from what they are attached to;
 e.g., the meaning of the `index` attribute on a `dim` operation is defined by
 the `dim` operation. Dialect attributes, on the other hand, derive their context

mlir/docs/Rationale/Rationale.md

if (a[i][j] == key) {
       s[i] = j;
       break;
     }
   }
 }
 ```
 
 The presence of dynamic control flow leads to an inner non-affine function
-nested in an outer function that using affine loops.
+nested in an outer function that uses affine loops.
 
 ```mlir
-func @search(%A: memref<?x?xi32, %S: <?xi32>, %key : i32) {
+func @search(%A: memref<?x?xi32>, %S: <?xi32>, %key : i32) {
   %ni = dim %A, 0 : memref<?x?xi32>
   // This loop can be parallelized
   affine.for %i = 0 to %ni {
     call @search_body (%A, %S, %key, %i) : (memref<?x?xi32>, memref<?xi32>, i32, i32)
   }
   return
 }