[Docs] Fix relative links in tutorial.
Update relative links in Kaleidoscope tutorial.
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst
index 7b4e24d..5364b17 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl03.rst
@@ -198,22 +198,22 @@
suffix. Local value names for instructions are purely optional, but it
makes it much easier to read the IR dumps.
-`LLVM instructions <../LangRef.html#instruction-reference>`_ are constrained by strict
+`LLVM instructions <../../LangRef.html#instruction-reference>`_ are constrained by strict
rules: for example, the Left and Right operators of an `add
-instruction <../LangRef.html#add-instruction>`_ must have the same type, and the
+instruction <../../LangRef.html#add-instruction>`_ must have the same type, and the
result type of the add must match the operand types. Because all values
in Kaleidoscope are doubles, this makes for very simple code for add,
sub and mul.
On the other hand, LLVM specifies that the `fcmp
-instruction <../LangRef.html#fcmp-instruction>`_ always returns an 'i1' value (a
+instruction <../../LangRef.html#fcmp-instruction>`_ always returns an 'i1' value (a
one bit integer). The problem with this is that Kaleidoscope wants the
value to be a 0.0 or 1.0 value. In order to get these semantics, we
combine the fcmp instruction with a `uitofp
-instruction <../LangRef.html#uitofp-to-instruction>`_. This instruction converts its
+instruction <../../LangRef.html#uitofp-to-instruction>`_. This instruction converts its
input integer into a floating point value by treating the input as an
unsigned value. In contrast, if we used the `sitofp
-instruction <../LangRef.html#sitofp-to-instruction>`_, the Kaleidoscope '<' operator
+instruction <../../LangRef.html#sitofp-to-instruction>`_, the Kaleidoscope '<' operator
would return 0.0 and -1.0, depending on the input value.
.. code-block:: c++
@@ -246,14 +246,14 @@
Once we have the function to call, we recursively codegen each argument
that is to be passed in, and create an LLVM `call
-instruction <../LangRef.html#call-instruction>`_. Note that LLVM uses the native C
+instruction <../../LangRef.html#call-instruction>`_. Note that LLVM uses the native C
calling conventions by default, allowing these calls to also call into
standard library functions like "sin" and "cos", with no additional
effort.
This wraps up our handling of the four basic expressions that we have so
far in Kaleidoscope. Feel free to go in and add some more. For example,
-by browsing the `LLVM language reference <../LangRef.html>`_ you'll find
+by browsing the `LLVM language reference <../../LangRef.html>`_ you'll find
several other interesting instructions that are really easy to plug into
our basic framework.
@@ -297,7 +297,7 @@
The final line above actually creates the IR Function corresponding to
the Prototype. This indicates the type, linkage and name to use, as
well as which module to insert into. "`external
-linkage <../LangRef.html#linkage>`_" means that the function may be
+linkage <../../LangRef.html#linkage>`_" means that the function may be
defined outside the current module and/or that it is callable by
functions outside the module. The Name passed in is the name the user
specified: since "``TheModule``" is specified, this name is registered
@@ -385,7 +385,7 @@
we call the ``codegen()`` method for the root expression of the function. If no
error happens, this emits code to compute the expression into the entry block
and returns the value that was computed. Assuming no error, we then create an
-LLVM `ret instruction <../LangRef.html#ret-instruction>`_, which completes the function.
+LLVM `ret instruction <../../LangRef.html#ret-instruction>`_, which completes the function.
Once the function is built, we call ``verifyFunction``, which is
provided by LLVM. This function does a variety of consistency checks on
the generated code, to determine if our compiler is doing everything
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst
index bf4e239..b643ae5 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl04.rst
@@ -117,8 +117,8 @@
program). It also supports and includes "per-function" passes which just
operate on a single function at a time, without looking at other
functions. For more information on passes and how they are run, see the
-`How to Write a Pass <../WritingAnLLVMPass.html>`_ document and the
-`List of LLVM Passes <../Passes.html>`_.
+`How to Write a Pass <../../WritingAnLLVMPass.html>`_ document and the
+`List of LLVM Passes <../../Passes.html>`_.
For Kaleidoscope, we are currently generating functions on the fly, one
at a time, as the user types them in. We aren't shooting for the
@@ -130,7 +130,7 @@
optimizer until the entire file has been parsed.
In order to get per-function optimizations going, we need to set up a
-`FunctionPassManager <../WritingAnLLVMPass.html#what-passmanager-doesr>`_ to hold
+`FunctionPassManager <../../WritingAnLLVMPass.html#what-passmanager-doesr>`_ to hold
and organize the LLVM optimizations that we want to run. Once we have
that, we can add a set of optimizations to run. We'll need a new
FunctionPassManager for each module that we want to optimize, so we'll
@@ -207,7 +207,7 @@
LLVM provides a wide variety of optimizations that can be used in
certain circumstances. Some `documentation about the various
-passes <../Passes.html>`_ is available, but it isn't very complete.
+passes <../../Passes.html>`_ is available, but it isn't very complete.
Another good source of ideas can come from looking at the passes that
``Clang`` runs to get started. The "``opt``" tool allows you to
experiment with passes from the command line, so you can see if they do
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst
index 0e61c07..725423f 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl05.rst
@@ -217,7 +217,7 @@
To visualize the control flow graph, you can use a nifty feature of the
LLVM '`opt <http://llvm.org/cmds/opt.html>`_' tool. If you put this LLVM
IR into "t.ll" and run "``llvm-as < t.ll | opt -analyze -view-cfg``", `a
-window will pop up <../ProgrammersManual.html#viewing-graphs-while-debugging-code>`_ and you'll
+window will pop up <../../ProgrammersManual.html#viewing-graphs-while-debugging-code>`_ and you'll
see this graph:
.. figure:: LangImpl05-cfg.png
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst
index 31e2ffb..14501fd 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl07.rst
@@ -105,7 +105,7 @@
differs from some other compiler systems, which do try to version memory
objects. In LLVM, instead of encoding dataflow analysis of memory into
the LLVM IR, it is handled with `Analysis
-Passes <../WritingAnLLVMPass.html>`_ which are computed on demand.
+Passes <../../WritingAnLLVMPass.html>`_ which are computed on demand.
With this in mind, the high-level idea is that we want to make a stack
variable (which lives in memory, because it is on the stack) for each
@@ -120,7 +120,7 @@
*name* actually refers to the address for that space. Stack variables
work the same way, except that instead of being declared with global
variable definitions, they are declared with the `LLVM alloca
-instruction <../LangRef.html#alloca-instruction>`_:
+instruction <../../LangRef.html#alloca-instruction>`_:
.. code-block:: llvm
@@ -223,7 +223,7 @@
funny pointer arithmetic is involved, the alloca will not be
promoted.
#. mem2reg only works on allocas of `first
- class <../LangRef.html#first-class-types>`_ values (such as pointers,
+ class <../../LangRef.html#first-class-types>`_ values (such as pointers,
scalars and vectors), and only if the array size of the allocation is
1 (or missing in the .ll file). mem2reg is not capable of promoting
structs or arrays to registers. Note that the "sroa" pass is
@@ -249,7 +249,7 @@
variables that only have one assignment point, good heuristics to
avoid insertion of unneeded phi nodes, etc.
- Needed for debug info generation: `Debug information in
- LLVM <../SourceLevelDebugging.html>`_ relies on having the address of
+ LLVM <../../SourceLevelDebugging.html>`_ relies on having the address of
the variable exposed so that debug info can be attached to it. This
technique dovetails very naturally with this style of debug info.
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
index 789042b..6d8a131 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
@@ -51,9 +51,9 @@
extending the type system in all sorts of interesting ways. Simple
arrays are very easy and are quite useful for many different
applications. Adding them is mostly an exercise in learning how the
- LLVM `getelementptr <../LangRef.html#getelementptr-instruction>`_ instruction
+ LLVM `getelementptr <../../LangRef.html#getelementptr-instruction>`_ instruction
works: it is so nifty/unconventional, it `has its own
- FAQ <../GetElementPtr.html>`_!
+ FAQ <../../GetElementPtr.html>`_!
- **standard runtime** - Our current language allows the user to access
arbitrary external functions, and we use it for things like "printd"
and "putchard". As you extend the language to add higher-level
@@ -66,10 +66,10 @@
memory, either with calls to the standard libc malloc/free interface
or with a garbage collector. If you would like to use garbage
collection, note that LLVM fully supports `Accurate Garbage
- Collection <../GarbageCollection.html>`_ including algorithms that
+ Collection <../../GarbageCollection.html>`_ including algorithms that
move objects and need to scan/update the stack.
- **exception handling support** - LLVM supports generation of `zero
- cost exceptions <../ExceptionHandling.html>`_ which interoperate with
+ cost exceptions <../../ExceptionHandling.html>`_ which interoperate with
code compiled in other languages. You could also generate code by
implicitly making every function return an error value and checking
it. You could also make explicit use of setjmp/longjmp. There are