Fix a few broken links (llvm#87098)

References to headings need to be preceded with a slash. Also,
references to headings on the same page do not need to contain the name
of the document (omitting the document name means if the name changes
the links will still be valid).

I double checked the links by building [the
website](https://github.com/llvm/mlir-www):

```shell
./mlir-www-helper.sh --install-docs ../llvm-project website
cd website && hugo serve
```

Author: mlevesquedion

mlir/docs/DefiningDialects/AttributesAndTypes.md

@@ -14,8 +14,8 @@ from the [MLIR LangRef](../LangRef.md).
 
 Attributes are the mechanism for specifying constant data on operations in
 places where a variable is never allowed - e.g. the comparison predicate of a
-[`arith.cmpi` operation](../Dialects/ArithOps.md#arithcmpi-mlirarithcmpiop), or
-the underlying value of a [`arith.constant` operation](../Dialects/ArithOps.md#arithconstant-mlirarithconstantop).
+[`arith.cmpi` operation](../Dialects/ArithOps.md/#arithcmpi-arithcmpiop), or
+the underlying value of a [`arith.constant` operation](../Dialects/ArithOps.md/#arithconstant-arithconstantop).
 Each operation has an attribute dictionary, which associates a set of attribute
 names to attribute values.
 
@@ -24,15 +24,15 @@ names to attribute values.
 Every SSA value, such as operation results or block arguments, in MLIR has a type
 defined by the type system. MLIR has an open type system with no fixed list of types,
 and there are no restrictions on the abstractions they represent. For example, take
-the following [Arithmetic AddI operation](../Dialects/ArithOps.md#arithaddi-mlirarithaddiop):
+the following [Arithmetic AddI operation](../Dialects/ArithOps.md/#arithaddi-arithaddiop):
 
 ```mlir
   %result = arith.addi %lhs, %rhs : i64
 ```
 
 It takes two input SSA values (`%lhs` and `%rhs`), and returns a single SSA
 value (`%result`). The inputs and outputs of this operation are of type `i64`,
-which is an instance of the [Builtin IntegerType](../Dialects/Builtin.md#integertype).
+which is an instance of the [Builtin IntegerType](../Dialects/Builtin.md/#integertype).
 
 ## Attributes and Types
 

mlir/docs/DefiningDialects/_index.md

@@ -10,8 +10,8 @@ Before diving into how to define these constructs, below is a quick refresher
 from the [MLIR LangRef](../LangRef.md).
 
 Dialects are the mechanism by which to engage with and extend the MLIR
-ecosystem. They allow for defining new [attributes](../LangRef.md#attributes),
-[operations](../LangRef.md#operations), and [types](../LangRef.md#type-system).
+ecosystem. They allow for defining new [attributes](../LangRef.md/#attributes),
+[operations](../LangRef.md/#operations), and [types](../LangRef.md/#type-system).
 Dialects are used to model a variety of different abstractions; from traditional
 [arithmetic](../Dialects/ArithOps.md) to
 [pattern rewrites](../Dialects/PDLOps.md); and is one of the most fundamental
@@ -196,7 +196,7 @@ only the declaration of the destructor is generated for the Dialect class.
 
 ### Discardable Attribute Verification
 
-As described by the [MLIR Language Reference](../LangRef.md#attributes),
+As described by the [MLIR Language Reference](../LangRef.md/#attributes),
 *discardable attribute* are a type of attribute that has its semantics defined
 by the dialect whose name prefixes that of the attribute. For example, if an
 operation has an attribute named `gpu.contained_module`, the `gpu` dialect
@@ -270,7 +270,7 @@ void *MyDialect::getRegisteredInterfaceForOp(TypeID typeID, StringAttr opName);
 ```
 
 For a more detail description of the expected usages of this hook, view the detailed 
-[interface documentation](../Interfaces.md#dialect-fallback-for-opinterface).
+[interface documentation](../Interfaces.md/#dialect-fallback-for-opinterface).
 
 ### Default Attribute/Type Parsers and Printers 
 

mlir/docs/Dialects/Linalg/_index.md

@@ -279,7 +279,7 @@ loops but previous experience shows that the abstraction generalizes.
 
 A `linalg.generic` op has a compute payload that is fully generic thanks to the
 use of
-[Regions](https://github.com/llvm/llvm-project/blob/58265ad42a90ae8905be6a447cb42e53529a54a0/mlir/docs/LangRef.md#regions).
+[Regions](https://github.com/llvm/llvm-project/blob/58265ad42a90ae8905be6a447cb42e53529a54a0/mlir/docs/LangRef.md/#regions).
 
 The region takes as arguments the scalar elemental types of the tensor or buffer
 operands of the `linalg.generic`. For flexibility and ability to match library

mlir/docs/Dialects/Transform.md

@@ -84,11 +84,11 @@ try to be explicitly typed when possible.
 
 The transform IR values have transform IR types, which should implement exactly one of:
 
-  * [TransformHandleTypeInterface](Transform.md#transformhandletypeinterface-transformhandletypeinterface),
+  * [TransformHandleTypeInterface](#transformhandletypeinterface-transformhandletypeinterface),
 
-  * [TransformValueHandleTypeInterface](Transform.md#transformvaluehandletypeinterface-transformvaluehandletypeinterface),
+  * [TransformValueHandleTypeInterface](#transformvaluehandletypeinterface-transformvaluehandletypeinterface),
 
-  * [TransformParamTypeInterface](Transform.md##transformparamtypeinterface-transformparamtypeinterface).
+  * [TransformParamTypeInterface](#transformparamtypeinterface-transformparamtypeinterface).
 
 The goal of these type interfaces, beyond providing a common base for accepted
 types, is to verify the properties of the associated objects. For example, a

mlir/docs/LangRef.md

@@ -761,7 +761,7 @@ attribute-value ::= attribute-alias | dialect-attribute | builtin-attribute
 
 Attributes are the mechanism for specifying constant data on operations in
 places where a variable is never allowed - e.g. the comparison predicate of a
-[`cmpi` operation](Dialects/ArithOps.md#arithcmpi-mlirarithcmpiop). Each operation has an
+[`cmpi` operation](Dialects/ArithOps.md/#arithcmpi-arithcmpiop). Each operation has an
 attribute dictionary, which associates a set of attribute names to attribute
 values. MLIR's builtin dialect provides a rich set of
 [builtin attribute values](#builtin-attribute-values) out of the box (such as

mlir/docs/Rationale/SideEffectsAndSpeculation.md

@@ -4,8 +4,8 @@ This document outlines how MLIR models side effects and how speculation works in
 MLIR.
 
 This rationale only applies to operations used in
-[CFG regions](../LangRef.md#control-flow-and-ssacfg-regions). Side effect
-modeling in [graph regions](../LangRef.md#graph-regions) is TBD.
+[CFG regions](../LangRef.md/#control-flow-and-ssacfg-regions). Side effect
+modeling in [graph regions](../LangRef.md/#graph-regions) is TBD.
 
 [TOC]
 

mlir/docs/TargetLLVMIR.md

@@ -41,7 +41,7 @@ they use or produce `memref`-typed values.
 
 The process relies on the [Dialect Conversion](DialectConversion.md)
 infrastructure and, in particular, on the
-[materialization](DialectConversion.md#type-conversion) hooks of `TypeConverter`
+[materialization](DialectConversion.md/#type-conversion) hooks of `TypeConverter`
 to support progressive lowering by injecting `unrealized_conversion_cast`
 operations between converted and unconverted operations. After multiple partial
 conversions to the LLVM dialect are performed, the cast operations that became
@@ -58,7 +58,7 @@ same type converter.
 
 #### LLVM Dialect-compatible Types
 
-The types [compatible](Dialects/LLVM.md#built-in-type-compatibility) with the
+The types [compatible](Dialects/LLVM.md/#built-in-type-compatibility) with the
 LLVM dialect are kept as is.
 
 #### Complex Type
@@ -188,7 +188,7 @@ Function types are converted to LLVM dialect function types as follows:
     arguments to allow for specifying metadata such as aliasing information on
     individual pointers;
 -   the conversion of `memref`-typed arguments is subject to
-    [calling conventions](TargetLLVMIR.md#calling-conventions).
+    [calling conventions](#calling-conventions).
 -   if a function type has boolean attribute `func.varargs` being set, the
     converted LLVM function will be variadic.
 
@@ -364,7 +364,7 @@ llvm.func @bar() {
 
 The default calling convention converts `memref`-typed function arguments to
 LLVM dialect literal structs
-[defined above](TargetLLVMIR.md#ranked-memref-types) before unbundling them into
+[defined above](#ranked-memref-types) before unbundling them into
 individual scalar arguments.
 
 Examples:

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

@@ -383,7 +383,7 @@ void MulOp::inferShapes() { getResult().setType(getLhs().getType()); }
 At this point, each of the necessary Toy operations provide a mechanism by which
 to infer their output shapes. The ShapeInferencePass will operate on functions:
 it will run on each function in isolation. MLIR also supports general
-[OperationPasses](../../PassManagement.md#operation-pass) that run on any
+[OperationPasses](../../PassManagement.md/#operation-pass) that run on any
 isolated operation, but here our module only contains functions, so there is no
 need to generalize to all operations.
 

mlir/docs/Tutorials/transform/Ch4.md

@@ -27,7 +27,7 @@ directly within the transform dialect.
 ## Simple match
 
 Let us reconsider the “fully connected layer” example from [Chapter
-1](Ch1.md#chaining-transformations-with-handles), reproduced below for
+1](Ch1.md/#chaining-transformations-with-handles), reproduced below for
 convenience.