[mlir] NFC: Fix broken links in docs

[kiszk]

Summary

This commit fixes missing links that are caused by the repository movement.

[rriddle]

mlir/docs/OpDefinitions.md

1206–1210

Can we use relative paths for these instead? Same with the fixes in the other files.

[rriddle]

mlir/docs/OpDefinitions.md

1206–1210

(I mean for the ones where it makes sense, i.e. StringAttr, etc.)

[kiszk]

• address review comment to use relative paths

[kiszk]

mlir/docs/OpDefinitions.md

1206–1210

Sure, I will address this

[rriddle]

Approval pending comments addressed.

[jpienaar]

Thanks

[kiszk]

I do not have commit rights to the repository. Could someone commit this change?
Kazuaki Ishizaki <[e-mail]>

mlir/docs/DeclarativeRewrites.md

 
 ### Compilation error: no matching member function for call to 'build'
 
 This is because DRR is failing to call a `build()` method with result type
 deduction ability. See [building operations](#building-operations) for more
 details.
 
 [TableGen]: https://llvm.org/docs/TableGen/index.html
-[OpBase]: https://github.com/tensorflow/mlir/blob/master/include/mlir/IR/OpBase.td
+[OpBase]: https://github.com/llvm/llvm-project/blob/master/mlir/include/mlir/IR/OpBase.td

mlir/docs/DefiningAttributesAndTypes.md

 ### Reserving a range of type kinds
 
 Types in MLIR rely on having a unique `kind` value to ensure that casting checks
 remain extremely
 efficient([rationale](Rationale.md#reserving-dialect-type-kinds). For a dialect
 author, this means that a range of type `kind` values must be explicitly, and
 statically, reserved. A dialect can reserve a range of values by adding a new
 entry to the
-[DialectSymbolRegistry](https://github.com/tensorflow/mlir/blob/master/include/mlir/IR/DialectSymbolRegistry.def).
+[DialectSymbolRegistry](https://github.com/llvm/llvm-project/blob/master/mlir/include/mlir/IR/DialectSymbolRegistry.def).
 To support out-of-tree and experimental dialects, the registry predefines a set
 of privates ranges, `PRIVATE_EXPERIMENTAL_[0-9]`, that are free for immediate
 use.
 
 ```c++
 DEFINE_SYM_KIND_RANGE(LINALG) // Linear Algebra Dialect
 DEFINE_SYM_KIND_RANGE(TOY)    // Toy language (tutorial) Dialect
 

mlir/docs/LangRef.md

 # MLIR Specification
 
 MLIR (Multi-Level IR) is a compiler intermediate representation with
 similarities to traditional three-address SSA representations (like
 [LLVM IR](http://llvm.org/docs/LangRef.html) or
 [SIL](https://github.com/apple/swift/blob/master/docs/SIL.rst)), but which
 introduces notions from polyhedral loop optimization as first-class concepts.
 This hybrid design is optimized to represent, analyze, and transform high level
 dataflow graphs as well as target-specific code generated for high performance
 data parallel systems. Beyond its representational capabilities, its single
 continuous design provides a framework to lower from dataflow graphs to
 high-performance target-specific code.
 
 This document defines and describes the key concepts in MLIR, and is intended to
 be a dry reference document - the [rationale documentation](Rationale.md),
-[glossary](Glossary.md), and other content are hosted elsewhere.
+[glossary](https://mlir.llvm.org/getting_started/Glossary/), and other content are hosted elsewhere.
 
 MLIR is designed to be used in three different forms: a human-readable textual
 form suitable for debugging, an in-memory form suitable for programmatic
 transformations and analysis, and a compact serialized form suitable for storage
 and transport. The different forms all describe the same semantic content. This
 document describes the human-readable textual form.
 
 [TOC]

 nested within a different symbol table.
 
 This attribute can only be held internally by
 [array attributes](#array-attribute) and
 [dictionary attributes](#dictionary-attribute)(including the top-level operation
 attribute dictionary), i.e. no other attribute kinds such as Locations or
 extended attribute kinds. If a reference to a symbol is necessary from outside
 of the symbol table that the symbol is defined in, a
-[string attribute](string-attribute) can be used to refer to the symbol name.
+[string attribute](#string-attribute) can be used to refer to the symbol name.
 
 **Rationale:** Given that MLIR models global accesses with symbol references, to
 enable efficient multi-threading, it becomes difficult to effectively reason
 about their uses. By restricting the places that can legally hold a symbol
 reference, we can always opaquely reason about a symbols usage characteristics.
 
 #### Type Attribute
 

mlir/docs/OpDefinitions.md

 function, the reference implementation of the operation will be used to derive
 the shape function. The reference implementation is general and can support the
 arbitrary computations needed to specify output shapes.
 
 [TableGen]: https://llvm.org/docs/TableGen/index.html
 [TableGenIntro]: https://llvm.org/docs/TableGen/LangIntro.html
 [TableGenRef]: https://llvm.org/docs/TableGen/LangRef.html
 [TableGenBackend]: https://llvm.org/docs/TableGen/BackEnds.html#introduction
-[OpBase]: https://github.com/tensorflow/mlir/blob/master/include/mlir/IR/OpBase.td
-[OpDefinitionsGen]: https://github.com/tensorflow/mlir/blob/master/tools/mlir-tblgen/OpDefinitionsGen.cpp
-[EnumsGen]: https://github.com/tensorflow/mlir/blob/master/tools/mlir-tblgen/EnumsGen.cpp
-[StringAttr]: https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md#string-attribute
-[IntegerAttr]: https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md#integer-attribute
+[OpBase]: ../include/mlir/IR/OpBase.td
+[OpDefinitionsGen]: ../tools/mlir-tblgen/OpDefinitionsGen.cpp
+[EnumsGen]: ../tools/mlir-tblgen/EnumsGen.cpp
+[StringAttr]: LangRef.md#string-attribute
+[IntegerAttr]: LangRef.md#integer-attribute