Improve documentation, as described below.

* Fix broken fragment identifiers.
* Use relative links when possible.
* Remove unused {#mainpage} from index.md
* Use consistent formatting for subheaders; e.g.

Use:
   ## Subheader

Instead of:
   Subheader
   ----------

Documentation/index.md

@@ -1,4 +1,4 @@
-# LLILC {#mainpage}
+# LLILC
 
 ## Introduction
 Welcome to LLILC.

Documentation/llilc-arch.md

@@ -43,17 +43,17 @@ for the JIT compilation model, and within the native runtime for the AOT model.
 on the heap are used to identify fields with GC references, and the JIT is required to report stack slots and registers that 
 contain GC references.  This information is used by the garbage collector for updating references when heap objects 
 are relocated.  A discussion of the garbage collector as used by LLILC is 
-[here](https://github.com/dotnet/llilc/blob/master/Documentation/llilc-gc.md).
+[here](llilc-gc.md).
 
 ####MSIL reader
 
 The key component needed to start testing code generation out of LLVM and get basic methods working 
 is an MSIL reader.  This component takes a request from [CoreCLR](https://github.com/dotnet/coreclr) to 
 compile a method, reads in all the method MSIL, maps the required types into LLVM, and translates the MSIL 
-opcodes into BitCode. The base Reader code is [here](https://github.com/dotnet/llilc/blob/master/lib/Reader/reader.cpp) 
+opcodes into BitCode. The base Reader code is [here](../lib/Reader/reader.cpp) 
 and the main entry point is ReaderBase::msilToIR().  From this starting point MSIL is converted into equivalent 
 BitCode.  In organization the reader is made up of a base component that interfaces with the CLR/EE interface 
-and [readerir](https://github.com/dotnet/llilc/blob/master/lib/Reader/readerir.cpp) which is responsible 
+and [readerir](../lib/Reader/readerir.cpp) which is responsible 
 for generating the actual BitCode.  This separation of concerns allows for easier refactoring and simplifies 
 BitCode creation.
 
@@ -69,7 +69,7 @@ to compile a method one method at a time, we currently would not get any benefit
 performed by the runtime.)
 
 There is a further discussion of how we're modeling the managed code semantics within LLVM in a following 
-[section](##Managed Semantics in LLVM). 
+[section](#managed-semantics-in-llvm).
 
 ####IL Transforms
 
@@ -98,7 +98,7 @@ EH can be found [here](https://msdn.microsoft.com/en-us/library/ms173162.aspx).
 the ECMA spec [here](http://www.ecma-international.org/publications/standards/Ecma-335.htm). 
 In LLILC we will explicitly expand the CLR required checks in to explicit flow, while for the additional clauses, use 
 the funclet design that is emerging in LLVM to support MSVC-compatible EH.  A full description of our EH approach can be 
-found in our documentation [here](https://github.com/dotnet/llilc/blob/master/Documentation/llilc-jit-eh.md).
+found in our documentation [here](llilc-jit-eh.md).
 
 #### Ahead of Time (AOT) Compilation Driver
 
@@ -169,7 +169,7 @@ to gain more benefit from the mid-level optimizer.
 
 ####Interior vs base pointers
 The GC used by the CLR differentiates between reported base pointers and interior pointers (see 
-[Garbage Collection](https://github.com/dotnet/llilc/blob/master/Documentation/llilc-gc.md#interior-pointers) doc for 
+[Garbage Collection](llilc-gc.md#interior-pointers) doc for 
 more details).  In simple terms an interior pointer results from an arithmetic operation on a base pointer if the resulting 
 pointer is still contained within the object being referenced. (Exterior pointers are not supported.) While all pointers can 
 be reported as interior this will increase the overhead of the GC since more checks are required to establish the object 

Documentation/llilc-jit-eh.md

@@ -1,8 +1,6 @@
-Exception Handling in the LLILC JIT
-========================================
+# Exception Handling in the LLILC JIT
 
-Introduction
-------------
+## Introduction
 
 This document provides a high-level overview of the LLILC jit's processing
 of exception handling constructs in the code it compiles.  It is not a fully
@@ -25,8 +23,7 @@ This document pertains specifically to just-in-time compilation.  Details
 for ahead-of-time compilation would possibly differ.
 
 
-EH Constructs in MSIL
----------------------
+## EH Constructs in MSIL
 
 MSIL exception handling constructs are defined in [ECMA-335 Partitions I, II, and
 III](http://www.ecma-international.org/publications/standards/Ecma-335.htm).
@@ -67,8 +64,7 @@ handlers associated with protected regions being exited before transferring
 control to the `leave` target.
 
 
-Contract with CLR Execution Engine
-----------------------------------
+## Contract with CLR Execution Engine
 
 This section describes the constraints that the Execution Engine imposes on
 the jit (and its codegen) to support exception processing.
@@ -161,8 +157,7 @@ this section may differ for other architectures (particularly x86), where
 unwinding may proceed differently.
 
 
-LLVM IR Model for Exception/Cleanup Flow
-----------------------------------------
+## LLVM IR Model for Exception/Cleanup Flow
 
 Exception handling in LLVM is [documented at llvm.org](http://llvm.org/docs/ExceptionHandling.html).
 Briefly, exceptions may only be raised at [`invoke`
@@ -197,8 +192,7 @@ codegen) to collapse the explicit dispatch and to separate non-filter
 funclets by outlining handlers.
 
 
-Potential Sticking Points
--------------------------
+## Potential Sticking Points
 
 There are a number of design points where the .Net Jit/EE have taken a
 different approach than most of the targets that LLVM supports.  The
@@ -360,8 +354,7 @@ beginfinally/beginfault intrinsic that [LLILC will insert](#finally-handlers)
 at the start of each finally/fault handler.
 
 
-Translation from MSIL to LLVM IR in Reader
-------------------------------------------
+## Translation from MSIL to LLVM IR in Reader
 
 This section describes the processing of EH constructs in the MSIL Reader.
 The goal is to translate the MSIL constructs into IR constructs that match
@@ -478,8 +471,7 @@ then branch to the innermost finally handler whose protected region it
 exits.
 
 
-Translation from LLVM IR to EH Tables
--------------------------------------
+## Translation from LLVM IR to EH Tables
 
 The plan for LLILC is to use the LLVM code that is currently being developed
 to support native Windows EH in order to identify the structure of the
@@ -489,8 +481,7 @@ encoded in the two cases is essentially similar, so a mapping should be
 feasible.
 
 
-Staging Plan and Current Status
--------------------------------
+## Staging Plan and Current Status
 
 Full EH support will take a while to implement, and many jit tests don't
 throw exceptions at runtime and therefore don't require full EH support to
@@ -562,8 +553,7 @@ In summary, the plan/status is:
 ahead-of-time is TBD, based on future priorities.)
 
 
-Open Questions
---------------
+## Open Questions
 
  1. Can filter outlining leverage some of the same outlining utilities used
     by the late outlining of handlers in LLVM, or is it best performed

Documentation/llilc-reader.md

@@ -1,8 +1,6 @@
-LLILC Reader
-============
+# LLILC Reader
 
-Introduction
-------------
+## Introduction
 
 LLILC reader is part of LLILC JIT and is responsible for translating
 MSIL instructions into LLVM IR.  The semantics of MSIL instructions is
@@ -18,8 +16,7 @@ Engine.  The reader calls methods of that interface to resolve MSIL
 tokens, get information about types, fields, code locations and much
 more.
 
-Main Classes
-------------
+## Main Classes
 
 The two main classes comprising the reader are ReaderBase and GenIR.
 GenIR derives from ReaderBase. ReaderBase encapsulates MSIL processing
@@ -31,8 +28,7 @@ code more maintainable and easier to evolve.  A legacy jit was
 implemented using the same ReaderBase and a different implementation of
 GenIR.
 
-Reader Driver
--------------
+## Reader Driver
 
 The main driver for the reader is ReaderBase::msilToIR.  The driver has
 the steps below:
@@ -56,8 +52,7 @@ the steps below:
 
 -   Execute [Post-pass](#post-pass) to allow the client a chance to finish up
 
-Pre-pass
---------
+## Pre-pass
 
 An instance of GenIR translates a single function.  GenIR::readerPrePass
 is responsible for initial setup.  The steps it performs:
@@ -78,8 +73,7 @@ is responsible for initial setup.  The steps it performs:
 -   Check whether the function has features that the reader hasn’t
     implemented yet
 
-First Pass
-----------
+## First Pass
 
 First pass is responsible for building LLVM basic blocks. The only instructions
 that are inserted are terminating branches and switches. Blocks that end with
@@ -102,8 +96,7 @@ temporary target blocks with the real ones.  This may involve splitting a
 basic block if a target of a branch has offset that’s in the middle of
 the block.
 
-Second Pass
------------
+## Second Pass
 
 In the second pass the reader first walks the flow graph in depth-first preorder
 (starting with the head block) to identify unused blocks.  Then the reader walks
@@ -260,14 +253,12 @@ that propagate operand stacks in the order of MSIL offsets.  Note that
 [ECMA-335](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf)
 section III.1.7.5 prohibits non-empty operand stacks on backwards branches.
 
-Post-Pass
----------
+## Post-Pass
 
 The post-pass inserts the necessary code for keeping generic context
 alive and cleans up memory used by the reader.
 
-Future Work
------------
+## Future Work
 
 -   [Implement remaining MSIL instructions.](#user-content-Not%20implemented)