vendor/llvm/llvm-trunk-r238337

8 files changed, 46 insertions, 44 deletions

diff --git a/docs/tutorial/LangImpl1.rst b/docs/tutorial/LangImpl1.rst
index a2c5eeebf474..f4b019166af3 100644
--- a/docs/tutorial/LangImpl1.rst
+++ b/docs/tutorial/LangImpl1.rst
@@ -73,14 +73,21 @@ in the various pieces. The structure of the tutorial is:
    about this is how easy and trivial it is to construct SSA form in
    LLVM: no, LLVM does *not* require your front-end to construct SSA
    form!
--  `Chapter #8 <LangImpl8.html>`_: Conclusion and other useful LLVM
+-  `Chapter #8 <LangImpl8.html>`_: Extending the Language: Debug
+   Information - Having built a decent little programming language with
+   control flow, functions and mutable variables, we consider what it
+   takes to add debug information to standalone executables. This debug
+   information will allow you to set breakpoints in Kaleidoscope
+   functions, print out argument variables, and call functions - all
+   from within the debugger!
+-  `Chapter #9 <LangImpl8.html>`_: Conclusion and other useful LLVM
    tidbits - This chapter wraps up the series by talking about
    potential ways to extend the language, but also includes a bunch of
    pointers to info about "special topics" like adding garbage
    collection support, exceptions, debugging, support for "spaghetti
    stacks", and a bunch of other tips and tricks.
 
-By the end of the tutorial, we'll have written a bit less than 700 lines
+By the end of the tutorial, we'll have written a bit less than 1000 lines
 of non-comment, non-blank, lines of code. With this small amount of
 code, we'll have built up a very reasonable compiler for a non-trivial
 language including a hand-written lexer, parser, AST, as well as code
diff --git a/docs/tutorial/LangImpl3.rst b/docs/tutorial/LangImpl3.rst
index b7418ccf32a9..26ba4aae956c 100644
--- a/docs/tutorial/LangImpl3.rst
+++ b/docs/tutorial/LangImpl3.rst
@@ -85,7 +85,7 @@ structure that the LLVM IR uses to contain code.
 
 The ``Builder`` object is a helper object that makes it easy to generate
 LLVM instructions. Instances of the
-```IRBuilder`` <http://llvm.org/doxygen/IRBuilder_8h-source.html>`_
+`IRBuilder <http://llvm.org/doxygen/IRBuilder_8h-source.html>`_
 class template keep track of the current place to insert instructions
 and has methods to create new instructions.
 
diff --git a/docs/tutorial/LangImpl5.rst b/docs/tutorial/LangImpl5.rst
index 72e34b1c9cdd..ca2ffebc19a2 100644
--- a/docs/tutorial/LangImpl5.rst
+++ b/docs/tutorial/LangImpl5.rst
@@ -254,7 +254,7 @@ In `Chapter 7 <LangImpl7.html>`_ of this tutorial ("mutable variables"),
 we'll talk about #1 in depth. For now, just believe me that you don't
 need SSA construction to handle this case. For #2, you have the choice
 of using the techniques that we will describe for #1, or you can insert
-Phi nodes directly, if convenient. In this case, it is really really
+Phi nodes directly, if convenient. In this case, it is really
 easy to generate the Phi node, so we choose to do it directly.
 
 Okay, enough of the motivation and overview, lets generate code!
@@ -388,7 +388,7 @@ code:
 
 The first two lines here are now familiar: the first adds the "merge"
 block to the Function object (it was previously floating, like the else
-block above). The second block changes the insertion point so that newly
+block above). The second changes the insertion point so that newly
 created code will go into the "merge" block. Once that is done, we need
 to create the PHI node and set up the block/value pairs for the PHI.
 
diff --git a/docs/tutorial/LangImpl7.rst b/docs/tutorial/LangImpl7.rst
index 141f1389630f..648940785b09 100644
--- a/docs/tutorial/LangImpl7.rst
+++ b/docs/tutorial/LangImpl7.rst
@@ -632,7 +632,7 @@ own local variables, lets add this next!
 User-defined Local Variables
 ============================
 
-Adding var/in is just like any other other extensions we made to
+Adding var/in is just like any other extension we made to
 Kaleidoscope: we extend the lexer, the parser, the AST and the code
 generator. The first step for adding our new 'var/in' construct is to
 extend the lexer. As before, this is pretty trivial, the code looks like
@@ -856,5 +856,5 @@ Here is the code:
 .. literalinclude:: ../../examples/Kaleidoscope/Chapter7/toy.cpp
    :language: c++
 
-`Next: Conclusion and other useful LLVM tidbits <LangImpl8.html>`_
+`Next: Adding Debug Information <LangImpl8.html>`_
 
diff --git a/docs/tutorial/LangImpl8.rst b/docs/tutorial/LangImpl8.rst
index 7b02468180f5..0b9b39c84b75 100644
--- a/docs/tutorial/LangImpl8.rst
+++ b/docs/tutorial/LangImpl8.rst
@@ -1,6 +1,6 @@
-=======================================================
-Kaleidoscope: Extending the Language: Debug Information
-=======================================================
+======================================
+Kaleidoscope: Adding Debug Information
+======================================
 
 .. contents::
    :local:
@@ -187,13 +187,13 @@ expressions:
   static DIBuilder *DBuilder;
 
   struct DebugInfo {
-    DICompileUnit TheCU;
-    DIType DblTy;
+    DICompileUnit *TheCU;
+    DIType *DblTy;
 
-    DIType getDoubleTy();
+    DIType *getDoubleTy();
   } KSDbgInfo;
 
-  DIType DebugInfo::getDoubleTy() {
+  DIType *DebugInfo::getDoubleTy() {
     if (DblTy.isValid())
       return DblTy;
 
@@ -245,26 +245,26 @@ So the context:
 
 .. code-block:: c++
 
-  DIFile Unit = DBuilder->createFile(KSDbgInfo.TheCU.getFilename(),
-                                     KSDbgInfo.TheCU.getDirectory());
+  DIFile *Unit = DBuilder->createFile(KSDbgInfo.TheCU.getFilename(),
+                                      KSDbgInfo.TheCU.getDirectory());
 
-giving us a DIFile and asking the ``Compile Unit`` we created above for the
+giving us an DIFile and asking the ``Compile Unit`` we created above for the
 directory and filename where we are currently. Then, for now, we use some
 source locations of 0 (since our AST doesn't currently have source location
 information) and construct our function definition:
 
 .. code-block:: c++
 
-  DIDescriptor FContext(Unit);
+  DIScope *FContext = Unit;
   unsigned LineNo = 0;
   unsigned ScopeLine = 0;
-  DISubprogram SP = DBuilder->createFunction(
+  DISubprogram *SP = DBuilder->createFunction(
       FContext, Name, StringRef(), Unit, LineNo,
       CreateFunctionType(Args.size(), Unit), false /* internal linkage */,
-      true /* definition */, ScopeLine, DIDescriptor::FlagPrototyped, false, F);
+      true /* definition */, ScopeLine, DINode::FlagPrototyped, false, F);
 
-and we now have a DISubprogram that contains a reference to all of our metadata
-for the function.
+and we now have an DISubprogram that contains a reference to all of our
+metadata for the function.
 
 Source Locations
 ================
@@ -332,11 +332,11 @@ by constructing another small function:
   void DebugInfo::emitLocation(ExprAST *AST) {
     DIScope *Scope;
     if (LexicalBlocks.empty())
-      Scope = &TheCU;
+      Scope = TheCU;
     else
       Scope = LexicalBlocks.back();
     Builder.SetCurrentDebugLocation(
-        DebugLoc::get(AST->getLine(), AST->getCol(), DIScope(*Scope)));
+        DebugLoc::get(AST->getLine(), AST->getCol(), Scope));
   }
 
 that both tells the main ``IRBuilder`` where we are, but also what scope
@@ -348,10 +348,10 @@ of scopes:
 .. code-block:: c++
 
    std::vector<DIScope *> LexicalBlocks;
-   std::map<const PrototypeAST *, DIScope> FnScopeMap;
+   std::map<const PrototypeAST *, DIScope *> FnScopeMap;
 
-and keep a map of each function to the scope that it represents (a DISubprogram
-is also a DIScope).
+and keep a map of each function to the scope that it represents (an
+DISubprogram is also an DIScope).
 
 Then we make sure to:
 
@@ -393,15 +393,15 @@ argument allocas in ``PrototypeAST::CreateArgumentAllocas``.
 .. code-block:: c++
 
   DIScope *Scope = KSDbgInfo.LexicalBlocks.back();
-  DIFile Unit = DBuilder->createFile(KSDbgInfo.TheCU.getFilename(),
-                                     KSDbgInfo.TheCU.getDirectory());
-  DIVariable D = DBuilder->createLocalVariable(dwarf::DW_TAG_arg_variable,
-                                               *Scope, Args[Idx], Unit, Line,
-                                               KSDbgInfo.getDoubleTy(), Idx);
+  DIFile *Unit = DBuilder->createFile(KSDbgInfo.TheCU.getFilename(),
+                                      KSDbgInfo.TheCU.getDirectory());
+  DILocalVariable D = DBuilder->createLocalVariable(
+      dwarf::DW_TAG_arg_variable, Scope, Args[Idx], Unit, Line,
+      KSDbgInfo.getDoubleTy(), Idx);
 
   Instruction *Call = DBuilder->insertDeclare(
       Alloca, D, DBuilder->createExpression(), Builder.GetInsertBlock());
-  Call->setDebugLoc(DebugLoc::get(Line, 0, *Scope));
+  Call->setDebugLoc(DebugLoc::get(Line, 0, Scope));
 
 Here we're doing a few things. First, we're grabbing our current scope
 for the variable so we can say what range of code our variable is valid
diff --git a/docs/tutorial/LangImpl9.rst b/docs/tutorial/LangImpl9.rst
index 6f694931ef86..33987687dee6 100644
--- a/docs/tutorial/LangImpl9.rst
+++ b/docs/tutorial/LangImpl9.rst
@@ -14,9 +14,10 @@ grown our little Kaleidoscope language from being a useless toy, to
 being a semi-interesting (but probably still useless) toy. :)
 
 It is interesting to see how far we've come, and how little code it has
-taken. We built the entire lexer, parser, AST, code generator, and an
-interactive run-loop (with a JIT!) by-hand in under 700 lines of
-(non-comment/non-blank) code.
+taken. We built the entire lexer, parser, AST, code generator, an
+interactive run-loop (with a JIT!), and emitted debug information in
+standalone executables - all in under 1000 lines of (non-comment/non-blank)
+code.
 
 Our little language supports a couple of interesting features: it
 supports user defined binary and unary operators, it uses JIT
@@ -68,12 +69,6 @@ For example, try adding:
    collection, note that LLVM fully supports `Accurate Garbage
    Collection <../GarbageCollection.html>`_ including algorithms that
    move objects and need to scan/update the stack.
--  **debugger support** - LLVM supports generation of `DWARF Debug
-   info <../SourceLevelDebugging.html>`_ which is understood by common
-   debuggers like GDB. Adding support for debug info is fairly
-   straightforward. The best way to understand it is to compile some
-   C/C++ code with "``clang -g -O0``" and taking a look at what it
-   produces.
 -  **exception handling support** - LLVM supports generation of `zero
    cost exceptions <../ExceptionHandling.html>`_ which interoperate with
    code compiled in other languages. You could also generate code by
diff --git a/docs/tutorial/OCamlLangImpl3.rst b/docs/tutorial/OCamlLangImpl3.rst
index fd9f0e5cd3f4..10d463b93ac3 100644
--- a/docs/tutorial/OCamlLangImpl3.rst
+++ b/docs/tutorial/OCamlLangImpl3.rst
@@ -65,7 +65,7 @@ the top-level structure that the LLVM IR uses to contain code.
 
 The ``Codegen.builder`` object is a helper object that makes it easy to
 generate LLVM instructions. Instances of the
-```IRBuilder`` <http://llvm.org/doxygen/IRBuilder_8h-source.html>`_
+`IRBuilder <http://llvm.org/doxygen/IRBuilder_8h-source.html>`_
 class keep track of the current place to insert instructions and has
 methods to create new instructions.
 
diff --git a/docs/tutorial/OCamlLangImpl5.rst b/docs/tutorial/OCamlLangImpl5.rst
index b8ae3c58ddff..0faecfb9222e 100644
--- a/docs/tutorial/OCamlLangImpl5.rst
+++ b/docs/tutorial/OCamlLangImpl5.rst
@@ -336,7 +336,7 @@ for the 'then' block.
           let phi = build_phi incoming "iftmp" builder in
 
 The first two lines here are now familiar: the first adds the "merge"
-block to the Function object. The second block changes the insertion
+block to the Function object. The second changes the insertion
 point so that newly created code will go into the "merge" block. Once
 that is done, we need to create the PHI node and set up the block/value
 pairs for the PHI.