Update LLVM to r90226.

7 files changed, 212 insertions, 301 deletions

diff --git a/docs/AliasAnalysis.html b/docs/AliasAnalysis.html
index d0869601c626..6903ede08b48 100644
--- a/docs/AliasAnalysis.html
+++ b/docs/AliasAnalysis.html
@@ -225,12 +225,7 @@ method for testing dependencies between function calls.  This method takes two
 call sites (CS1 & CS2), returns NoModRef if the two calls refer to disjoint
 memory locations, Ref if CS1 reads memory written by CS2, Mod if CS1 writes to
 memory read or written by CS2, or ModRef if CS1 might read or write memory
-accessed by CS2.  Note that this relation is not commutative.  Clients that use
-this method should be predicated on the <tt>hasNoModRefInfoForCalls()</tt>
-method, which indicates whether or not an analysis can provide mod/ref
-information for function call pairs (most can not).  If this predicate is false,
-the client shouldn't waste analysis time querying the <tt>getModRefInfo</tt>
-method many times.</p>
+accessed by CS2.  Note that this relation is not commutative.</p>
 
 </div>
 
@@ -251,21 +246,6 @@ analysis implementations and can be put to good use by various clients.
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  The <tt>getMustAliases</tt> method
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>getMustAliases</tt> method returns all values that are known to
-always must alias a pointer.  This information can be provided in some cases for
-important objects like the null pointer and global values.  Knowing that a
-pointer always points to a particular function allows indirect calls to be
-turned into direct calls, for example.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
   The <tt>pointsToConstantMemory</tt> method
 </div>
 
@@ -969,7 +949,7 @@ analysis directly.</p>
 
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
   <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2009-04-25 23:11:37 +0200 (Sat, 25 Apr 2009) $
+  Last modified: $Date: 2009-11-22 17:01:44 +0100 (Sun, 22 Nov 2009) $
 </address>
 
 </body>
diff --git a/docs/CMake.html b/docs/CMake.html
index d83e3ad54565..40a2cec8e91b 100644
--- a/docs/CMake.html
+++ b/docs/CMake.html
@@ -251,10 +251,16 @@
     <i>-DLLVM_TARGETS_TO_BUILD="X86;PowerPC;Alpha"</i>.</dd>
 
   <dt><b>LLVM_BUILD_TOOLS</b>:BOOL</dt>
-  <dd>Build LLVM tools. Defaults to ON.</dd>
+  <dd>Build LLVM tools. Defaults to ON. Targets for building each tool
+    are generated in any case. You can build an tool separately by
+    invoking its target. For example, you can build <i>llvm-as</i>
+    with a makefile-based system executing <i>make llvm-as</i> on the
+    root of your build directory.</dd>
 
   <dt><b>LLVM_BUILD_EXAMPLES</b>:BOOL</dt>
-  <dd>Build LLVM examples. Defaults to ON.</dd>
+  <dd>Build LLVM examples. Defaults to OFF. Targets for building each
+    example are generated in any case. See documentation
+    for <i>LLVM_BUILD_TOOLS</i> above for more details.</dd>
 
   <dt><b>LLVM_ENABLE_THREADS</b>:BOOL</dt>
   <dd>Build with threads support, if available. Defaults to ON.</dd>
@@ -268,10 +274,21 @@
     compiler supports this flag. Some systems, like Windows, do not
     need this flag. Defaults to ON.</dd>
 
+  <dt><b>LLVM_ENABLE_WARNINGS</b>:BOOL</dt>
+  <dd>Enable all compiler warnings. Defaults to ON.</dd>
+
+  <dt><b>LLVM_ENABLE_PEDANTIC</b>:BOOL</dt>
+  <dd>Enable pedantic mode. This disable compiler specific extensions, is
+    possible. Defaults to ON.</dd>
+
+  <dt><b>LLVM_ENABLE_WERROR</b>:BOOL</dt>
+  <dd>Stop and fail build, if a compiler warning is
+    triggered. Defaults to OFF.</dd>
+
   <dt><b>LLVM_BUILD_32_BITS</b>:BOOL</dt>
   <dd>Build 32-bits executables and libraries on 64-bits systems. This
-  option is available only on some 64-bits unix systems. Defaults to
-  OFF.</dd>
+    option is available only on some 64-bits unix systems. Defaults to
+    OFF.</dd>
 
   <dt><b>LLVM_TARGET_ARCH</b>:STRING</dt>
   <dd>LLVM target to use for native code generation. This is required
diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod
index d3f640d64dcc..32516ad87b3e 100644
--- a/docs/CommandGuide/FileCheck.pod
+++ b/docs/CommandGuide/FileCheck.pod
@@ -224,7 +224,7 @@ The first check line matches a regex (<tt>%[a-z]+</tt>) and captures it into
 the variables "REGISTER".  The second line verifies that whatever is in REGISTER
 occurs later in the file after an "andw".  FileCheck variable references are
 always contained in <tt>[[ ]]</tt> pairs, are named, and their names can be
-formed with the regex "<tt>[a-zA-Z][a-zA-Z0-9]*</tt>".  If a colon follows the
+formed with the regex "<tt>[a-zA-Z_][a-zA-Z0-9_]*</tt>".  If a colon follows the
 name, then it is a definition of the variable, if not, it is a use.
 
 FileCheck variables can be defined multiple times, and uses always get the
diff --git a/docs/CommandGuide/llvmc.pod b/docs/CommandGuide/llvmc.pod
index e3031e123d38..e5e065116131 100644
--- a/docs/CommandGuide/llvmc.pod
+++ b/docs/CommandGuide/llvmc.pod
@@ -126,24 +126,31 @@ use the B<-Wo,> option.
 
 =item B<-I> I<directory>
 
-Add a directory to the header file search path.  This option can be
-repeated.
+Add a directory to the header file search path.
 
 =item B<-L> I<directory>
 
-Add I<directory> to the library search path.  This option can be
-repeated.
+Add I<directory> to the library search path.
+
+=item B<-F> I<directory>
+
+Add I<directory> to the framework search path.
 
 =item B<-l>I<name>
 
 Link in the library libI<name>.[bc | a | so].  This library should
 be a bitcode library.
 
+=item B<-framework> I<name>
+
+Link in the library libI<name>.[bc | a | so].  This library should
+be a bitcode library.
+
 =item B<-emit-llvm>
 
-Make the output be LLVM bitcode (with B<-c>) or assembly (with B<-S>) instead
-of native object (or assembly).  If B<-emit-llvm> is given without either B<-c>
-or B<-S> it has no effect.
+Output LLVM bitcode (with B<-c>) or assembly (with B<-S>) instead of native
+object (or assembly).  If B<-emit-llvm> is given without either B<-c> or B<-S>
+it has no effect.
 
 =item B<-Wa>
 
@@ -157,6 +164,10 @@ Pass options to linker.
 
 Pass options to opt.
 
+=item B<-Wllc>
+
+Pass options to llc (code generator).
+
 =back
 
 =head1 EXIT STATUS
diff --git a/docs/LangRef.html b/docs/LangRef.html
index a417db011541..894ad4978043 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -291,6 +291,8 @@
             '<tt>llvm.trap</tt>' Intrinsic</a></li>
           <li><a href="#int_stackprotector">
             '<tt>llvm.stackprotector</tt>' Intrinsic</a></li>
+	  <li><a href="#int_objectsize">
+            '<tt>llvm.objectsize</tt>' Intrinsic</a></li>
         </ol>
       </li>
     </ol>
@@ -1440,11 +1442,6 @@ Classifications</a> </div>
   </tr>
 </table>
 
-<p>Note that the code generator does not yet support large integer types to be
-   used as function return types. The specific limit on how large a return type
-   the code generator can currently handle is target-dependent; currently it's
-   often 64 bits for 32-bit targets and 128 bits for 64-bit targets.</p>
-
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -1583,11 +1580,6 @@ Classifications</a> </div>
    length array type. An implementation of 'pascal style arrays' in LLVM could
    use the type "<tt>{ i32, [0 x float]}</tt>", for example.</p>
 
-<p>Note that the code generator does not yet support large aggregate types to be
-   used as function return types. The specific limit on how large an aggregate
-   return type the code generator can currently handle is target-dependent, and
-   also dependent on the aggregate element types.</p>
-
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -1680,11 +1672,6 @@ Classifications</a> </div>
   </tr>
 </table>
 
-<p>Note that the code generator does not yet support large aggregate types to be
-   used as function return types. The specific limit on how large an aggregate
-   return type the code generator can currently handle is target-dependent, and
-   also dependent on the aggregate element types.</p>
-
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -1775,8 +1762,7 @@ Classifications</a> </div>
 <p>A vector type is a simple derived type that represents a vector of elements.
    Vector types are used when multiple primitive data are operated in parallel
    using a single instruction (SIMD).  A vector type requires a size (number of
-   elements) and an underlying primitive data type.  Vectors must have a power
-   of two length (1, 2, 4, 8, 16 ...).  Vector types are considered
+   elements) and an underlying primitive data type.  Vector types are considered
    <a href="#t_firstclass">first class</a>.</p>
 
 <h5>Syntax:</h5>
@@ -1803,11 +1789,6 @@ Classifications</a> </div>
   </tr>
 </table>
 
-<p>Note that the code generator does not yet support large vector types to be
-   used as function return types. The specific limit on how large a vector
-   return type codegen can currently handle is target-dependent; currently it's
-   often a few times longer than a hardware vector register.</p>
-
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -2600,14 +2581,6 @@ Instruction</a> </div>
   ret { i32, i8 } { i32 4, i8 2 } <i>; Return a struct of values 4 and 2</i>
 </pre>
 
-<p>Note that the code generator does not yet fully support large
-   return values. The specific sizes that are currently supported are
-   dependent on the target. For integers, on 32-bit targets the limit
-   is often 64 bits, and on 64-bit targets the limit is often 128 bits.
-   For aggregate types, the current limits are dependent on the element
-   types; for example targets are often limited to 2 total integer
-   elements and 2 total floating-point elements.</p>
-
 </div>
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
@@ -7275,6 +7248,41 @@ LLVM</a>.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="int_objectsize">'<tt>llvm.objectsize</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+  declare i32 @llvm.objectsize.i32( i8* &lt;ptr&gt;, i32 &lt;type&gt; )
+  declare i64 @llvm.objectsize.i64( i8* &lt;ptr&gt;, i32 &lt;type&gt; )
+</pre>
+
+<h5>Overview:</h5>
+<p>The <tt>llvm.objectsize</tt> intrinsic returns the constant number of bytes
+   from <tt>ptr</tt> to the end of the object <tt>ptr</tt> points to if it
+   can deduce this at compile time.  If there are any side-effects in evaluating
+   the argument or it cannot deduce which objects <tt>ptr</tt> points to at compile
+   time the intrinsic returns <tt>(size_t) -1</tt> for <tt>type</tt> 0
+   or 1 and <tt>(size_t) 0</tt> for <tt>type</tt> 2 or 3.</p>
+
+<h5>Arguments:</h5>
+<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments.  The first
+   argument is a pointer to the object <tt>ptr</tt> and an integer <tt>type</tt>.
+   <tt>type</tt> is an integer ranging from 0 to 3. The lsb corresponds to
+   a return value based on whole objects, the second bit whether or not we
+   return the maximum or minimum remaining bytes computed.</p>
+
+<h5>Semantics:</h5>
+<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to either a constant
+   representing the size of the object concerned or <tt>(size_t) -1</tt> if
+   it cannot be determined at compile time.</p>
+
+</div>
+
 <!-- *********************************************************************** -->
 <hr>
 <address>
@@ -7285,7 +7293,7 @@ LLVM</a>.</p>
 
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
   <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2009-11-09 20:01:53 +0100 (Mon, 09 Nov 2009) $
+  Last modified: $Date: 2009-11-30 09:03:53 +0100 (Mon, 30 Nov 2009) $
 </address>
 
 </body>
diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html
index 9b7571ad0d4b..4aca52cc2637 100644
--- a/docs/SourceLevelDebugging.html
+++ b/docs/SourceLevelDebugging.html
@@ -37,15 +37,10 @@
     </ul></li>
     <li><a href="#format_common_intrinsics">Debugger intrinsic functions</a>
       <ul>
-      <li><a href="#format_common_stoppoint">llvm.dbg.stoppoint</a></li>
-      <li><a href="#format_common_func_start">llvm.dbg.func.start</a></li>
-      <li><a href="#format_common_region_start">llvm.dbg.region.start</a></li>
-      <li><a href="#format_common_region_end">llvm.dbg.region.end</a></li>
       <li><a href="#format_common_declare">llvm.dbg.declare</a></li>
     </ul></li>
-    <li><a href="#format_common_stoppoints">Representing stopping points in the
-                                           source program</a></li>
   </ol></li>
+  <li><a href="#format_common_lifetime">Object lifetimes and scoping</a></li>
   <li><a href="#ccxx_frontend">C/C++ front-end specific debug information</a>
   <ol>
     <li><a href="#ccxx_compile_units">C/C++ source file information</a></li>
@@ -763,92 +758,6 @@ DW_TAG_return_variable = 258
 
 <!-- ======================================================================= -->
 <div class="doc_subsubsection">
-  <a name="format_common_stoppoint">llvm.dbg.stoppoint</a>
-</div>
-
-<div class="doc_text">
-<pre>
-  void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint, uint, metadata)
-</pre>
-
-<p>This intrinsic is used to provide correspondence between the source file and
-   the generated code.  The first argument is the line number (base 1), second
-   argument is the column number (0 if unknown) and the third argument the
-   source <tt>%<a href="#format_compile_units">llvm.dbg.compile_unit</a></tt>.
-   Code following a call to this intrinsic will
-   have been defined in close proximity of the line, column and file. This
-   information holds until the next call
-   to <tt>%<a href="#format_common_stoppoint">lvm.dbg.stoppoint</a></tt>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
-  <a name="format_common_func_start">llvm.dbg.func.start</a>
-</div>
-
-<div class="doc_text">
-<pre>
-  void %<a href="#format_common_func_start">llvm.dbg.func.start</a>( metadata )
-</pre>
-
-<p>This intrinsic is used to link the debug information
-   in <tt>%<a href="#format_subprograms">llvm.dbg.subprogram</a></tt> to the
-   function. It defines the beginning of the function's declarative region
-   (scope). It also implies a call to
-   %<tt><a href="#format_common_stoppoint">llvm.dbg.stoppoint</a></tt> which
-   defines a source line "stop point". The intrinsic should be called early in
-   the function after the all the alloca instructions.  It should be paired off
-   with a closing
-   <tt>%<a href="#format_common_region_end">llvm.dbg.region.end</a></tt>.
-   The function's single argument is
-   the <tt>%<a href="#format_subprograms">llvm.dbg.subprogram.type</a></tt>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
-  <a name="format_common_region_start">llvm.dbg.region.start</a>
-</div>
-
-<div class="doc_text">
-<pre>
-  void %<a href="#format_common_region_start">llvm.dbg.region.start</a>( metadata )
-</pre>
-
-<p>This intrinsic is used to define the beginning of a declarative scope (ex.
-   block) for local language elements.  It should be paired off with a closing
-   <tt>%<a href="#format_common_region_end">llvm.dbg.region.end</a></tt>.  The
-   function's single argument is
-   the <tt>%<a href="#format_blocks">llvm.dbg.block</a></tt> which is
-   starting.</p>
-
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
-  <a name="format_common_region_end">llvm.dbg.region.end</a>
-</div>
-
-<div class="doc_text">
-<pre>
-  void %<a href="#format_common_region_end">llvm.dbg.region.end</a>( metadata )
-</pre>
-
-<p>This intrinsic is used to define the end of a declarative scope (ex. block)
-   for local language elements.  It should be paired off with an
-   opening <tt>%<a href="#format_common_region_start">llvm.dbg.region.start</a></tt>
-   or <tt>%<a href="#format_common_func_start">llvm.dbg.func.start</a></tt>.
-   The function's single argument is either
-   the <tt>%<a href="#format_blocks">llvm.dbg.block</a></tt> or
-   the <tt>%<a href="#format_subprograms">llvm.dbg.subprogram.type</a></tt>
-   which is ending.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
   <a name="format_common_declare">llvm.dbg.declare</a>
 </div>
 
@@ -867,68 +776,33 @@ DW_TAG_return_variable = 258
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="format_common_stoppoints">
-     Representing stopping points in the source program
-  </a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM debugger "stop points" are a key part of the debugging representation
-   that allows the LLVM to maintain simple semantics
-   for <a href="#debugopt">debugging optimized code</a>.  The basic idea is that
-   the front-end inserts calls to
-   the <a href="#format_common_stoppoint">%<tt>llvm.dbg.stoppoint</tt></a>
-   intrinsic function at every point in the program where a debugger should be
-   able to inspect the program (these correspond to places a debugger stops when
-   you "<tt>step</tt>" through it).  The front-end can choose to place these as
-   fine-grained as it would like (for example, before every subexpression
-   evaluated), but it is recommended to only put them after every source
-   statement that includes executable code.</p>
-
-<p>Using calls to this intrinsic function to demark legal points for the
-   debugger to inspect the program automatically disables any optimizations that
-   could potentially confuse debugging information.  To
-   non-debug-information-aware transformations, these calls simply look like
-   calls to an external function, which they must assume to do anything
-   (including reading or writing to any part of reachable memory).  On the other
-   hand, it does not impact many optimizations, such as code motion of
-   non-trapping instructions, nor does it impact optimization of subexpressions,
-   code duplication transformations, or basic-block reordering
-   transformations.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
   <a name="format_common_lifetime">Object lifetimes and scoping</a>
 </div>
 
 <div class="doc_text">
-<p>In many languages, the local variables in functions can have their lifetime
-   or scope limited to a subset of a function.  In the C family of languages,
+<p>In many languages, the local variables in functions can have their lifetimes
+   or scopes limited to a subset of a function.  In the C family of languages,
    for example, variables are only live (readable and writable) within the
    source block that they are defined in.  In functional languages, values are
    only readable after they have been defined.  Though this is a very obvious
-   concept, it is also non-trivial to model in LLVM, because it has no notion of
+   concept, it is non-trivial to model in LLVM, because it has no notion of
    scoping in this sense, and does not want to be tied to a language's scoping
    rules.</p>
 
-<p>In order to handle this, the LLVM debug format uses the notion of "regions"
-   of a function, delineated by calls to intrinsic functions.  These intrinsic
-   functions define new regions of the program and indicate when the region
-   lifetime expires.  Consider the following C fragment, for example:</p>
+<p>In order to handle this, the LLVM debug format uses the metadata attached to
+   llvm instructions to encode line nuber and scoping information. Consider the
+   following C fragment, for example:</p>
 
 <div class="doc_code">
 <pre>
 1.  void foo() {
-2.    int X = ...;
-3.    int Y = ...;
+2.    int X = 21;
+3.    int Y = 22;
 4.    {
-5.      int Z = ...;
-6.      ...
+5.      int Z = 23;
+6.      Z = X;
 7.    }
-8.    ...
+8.    X = Y;
 9.  }
 </pre>
 </div>
@@ -937,98 +811,129 @@ DW_TAG_return_variable = 258
 
 <div class="doc_code">
 <pre>
-void %foo() {
+define void @foo() nounwind ssp {
 entry:
-    %X = alloca int
-    %Y = alloca int
-    %Z = alloca int
-    
-    ...
-    
-    call void @<a href="#format_common_func_start">llvm.dbg.func.start</a>( metadata !0)
-    
-    call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 2, uint 2, metadata !1)
-    
-    call void @<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
-    call void @<a href="#format_common_declare">llvm.dbg.declare</a>({}* %Y, ...)
-    
-    <i>;; Evaluate expression on line 2, assigning to X.</i>
-    
-    call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 3, uint 2, metadata !1)
-    
-    <i>;; Evaluate expression on line 3, assigning to Y.</i>
-    
-    call void @<a href="#format_common_stoppoint">llvm.region.start</a>()
-    call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 5, uint 4, metadata !1)
-    call void @<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
-    
-    <i>;; Evaluate expression on line 5, assigning to Z.</i>
-    
-    call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 7, uint 2, metadata !1)
-    call void @<a href="#format_common_region_end">llvm.region.end</a>()
-    
-    call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 9, uint 2, metadata !1)
-    
-    call void @<a href="#format_common_region_end">llvm.region.end</a>()
-    
-    ret void
+  %X = alloca i32, align 4                        ; &lt;i32*&gt; [#uses=4]
+  %Y = alloca i32, align 4                        ; &lt;i32*&gt; [#uses=4]
+  %Z = alloca i32, align 4                        ; &lt;i32*&gt; [#uses=3]
+  %0 = bitcast i32* %X to { }*                    ; &lt;{ }*&gt; [#uses=1]
+  call void @llvm.dbg.declare({ }* %0, metadata !0), !dbg !7
+  store i32 21, i32* %X, !dbg !8
+  %1 = bitcast i32* %Y to { }*                    ; &lt;{ }*&gt; [#uses=1]
+  call void @llvm.dbg.declare({ }* %1, metadata !9), !dbg !10
+  store i32 22, i32* %Y, !dbg !11
+  %2 = bitcast i32* %Z to { }*                    ; &lt;{ }*&gt; [#uses=1]
+  call void @llvm.dbg.declare({ }* %2, metadata !12), !dbg !14
+  store i32 23, i32* %Z, !dbg !15
+  %tmp = load i32* %X, !dbg !16                   ; &lt;i32&gt; [#uses=1]
+  %tmp1 = load i32* %Y, !dbg !16                  ; &lt;i32&gt; [#uses=1]
+  %add = add nsw i32 %tmp, %tmp1, !dbg !16        ; &lt;i32&gt; [#uses=1]
+  store i32 %add, i32* %Z, !dbg !16
+  %tmp2 = load i32* %Y, !dbg !17                  ; &lt;i32&gt; [#uses=1]
+  store i32 %tmp2, i32* %X, !dbg !17
+  ret void, !dbg !18
 }
+
+declare void @llvm.dbg.declare({ }*, metadata) nounwind readnone
+
+!0 = metadata !{i32 459008, metadata !1, metadata !"X", 
+                metadata !3, i32 2, metadata !6}; [ DW_TAG_auto_variable ]
+!1 = metadata !{i32 458763, metadata !2}; [DW_TAG_lexical_block ]
+!2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"foo", metadata !"foo", 
+               metadata !"foo", metadata !3, i32 1, metadata !4, 
+               i1 false, i1 true}; [DW_TAG_subprogram ]
+!3 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", 
+                metadata !"/private/tmp", metadata !"clang 1.1", i1 true, 
+                i1 false, metadata !"", i32 0}; [DW_TAG_compile_unit ]
+!4 = metadata !{i32 458773, metadata !3, metadata !"", null, i32 0, i64 0, i64 0, 
+                i64 0, i32 0, null, metadata !5, i32 0}; [DW_TAG_subroutine_type ]
+!5 = metadata !{null}
+!6 = metadata !{i32 458788, metadata !3, metadata !"int", metadata !3, i32 0, 
+                i64 32, i64 32, i64 0, i32 0, i32 5}; [DW_TAG_base_type ]
+!7 = metadata !{i32 2, i32 7, metadata !1, null}
+!8 = metadata !{i32 2, i32 3, metadata !1, null}
+!9 = metadata !{i32 459008, metadata !1, metadata !"Y", metadata !3, i32 3, 
+                metadata !6}; [ DW_TAG_auto_variable ]
+!10 = metadata !{i32 3, i32 7, metadata !1, null}
+!11 = metadata !{i32 3, i32 3, metadata !1, null}
+!12 = metadata !{i32 459008, metadata !13, metadata !"Z", metadata !3, i32 5, 
+                 metadata !6}; [ DW_TAG_auto_variable ]
+!13 = metadata !{i32 458763, metadata !1}; [DW_TAG_lexical_block ]
+!14 = metadata !{i32 5, i32 9, metadata !13, null}
+!15 = metadata !{i32 5, i32 5, metadata !13, null}
+!16 = metadata !{i32 6, i32 5, metadata !13, null}
+!17 = metadata !{i32 8, i32 3, metadata !1, null}
+!18 = metadata !{i32 9, i32 1, metadata !2, null}
+</pre>
+</div>
+
+<p>This example illustrates a few important details about LLVM debugging
+   information. In particular, it shows how the <tt>llvm.dbg.declare</tt>
+   intrinsic and location information, which are attached to an instruction,
+   are applied together to allow a debugger to analyze the relationship between
+   statements, variable definitions, and the code used to implement the
+   function.</p>
+
+<div class="doc_code">
+<pre>
+call void @llvm.dbg.declare({ }* %0, metadata !0), !dbg !7   
 </pre>
 </div>
 
-<p>This example illustrates a few important details about the LLVM debugging
-   information.  In particular, it shows how the various intrinsics are applied
-   together to allow a debugger to analyze the relationship between statements,
-   variable definitions, and the code used to implement the function.</p>
-
-<p>The first
-   intrinsic <tt>%<a href="#format_common_func_start">llvm.dbg.func.start</a></tt>
-   provides a link with the <a href="#format_subprograms">subprogram
-   descriptor</a> containing the details of this function.  This call also
-   defines the beginning of the function region, bounded by
-   the <tt>%<a href="#format_common_region_end">llvm.region.end</a></tt> at the
-   end of the function.  This region is used to bracket the lifetime of
-   variables declared within.  For a function, this outer region defines a new
-   stack frame whose lifetime ends when the region is ended.</p>
-
-<p>It is possible to define inner regions for short term variables by using the
-   %<a href="#format_common_stoppoint"><tt>llvm.region.start</tt></a>
-   and <a href="#format_common_region_end"><tt>%llvm.region.end</tt></a> to
-   bound a region.  The inner region in this example would be for the block
-   containing the declaration of Z.</p>
-
-<p>Using regions to represent the boundaries of source-level functions allow
-   LLVM interprocedural optimizations to arbitrarily modify LLVM functions
-   without having to worry about breaking mapping information between the LLVM
-   code and the and source-level program.  In particular, the inliner requires
-   no modification to support inlining with debugging information: there is no
-   explicit correlation drawn between LLVM functions and their source-level
-   counterparts (note however, that if the inliner inlines all instances of a
-   non-strong-linkage function into its caller that it will not be possible for
-   the user to manually invoke the inlined function from a debugger).</p>
-
-<p>Once the function has been defined,
-   the <a href="#format_common_stoppoint"><tt>stopping point</tt></a>
-   corresponding to line #2 (column #2) of the function is encountered.  At this
-   point in the function, <b>no</b> local variables are live.  As lines 2 and 3
-   of the example are executed, their variable definitions are introduced into
-   the program using
-   %<a href="#format_common_declare"><tt>llvm.dbg.declare</tt></a>, without the
-   need to specify a new region.  These variables do not require new regions to
-   be introduced because they go out of scope at the same point in the program:
-   line 9.</p>
-
-<p>In contrast, the <tt>Z</tt> variable goes out of scope at a different time,
-   on line 7.  For this reason, it is defined within the inner region, which
-   kills the availability of <tt>Z</tt> before the code for line 8 is executed.
-   In this way, regions can support arbitrary source-language scoping rules, as
-   long as they can only be nested (ie, one scope cannot partially overlap with
-   a part of another scope).</p>
-
-<p>It is worth noting that this scoping mechanism is used to control scoping of
-   all declarations, not just variable declarations.  For example, the scope of
-   a C++ using declaration is controlled with this and could change how name
-   lookup is performed.</p>
+<p>The first intrinsic
+   <tt>%<a href="#format_common_declare">llvm.dbg.declare</a></tt>
+   encodes debugging information for the variable <tt>X</tt>. The metadata
+   <tt>!dbg !7</tt> attached to the intrinsic provides scope information for the
+   variable <tt>X</tt>.</p>
+
+<div class="doc_code">
+<pre>
+!7 = metadata !{i32 2, i32 7, metadata !1, null}
+!1 = metadata !{i32 458763, metadata !2}; [DW_TAG_lexical_block ]
+!2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"foo", 
+                metadata !"foo", metadata !"foo", metadata !3, i32 1, 
+                metadata !4, i1 false, i1 true}; [DW_TAG_subprogram ]   
+</pre>
+</div>
+
+<p>Here <tt>!7</tt> is metadata providing location information. It has four
+   fields: line number, column number, scope, and original scope. The original
+   scope represents inline location if this instruction is inlined inside a
+   caller, and is null otherwise. In this example, scope is encoded by
+   <tt>!1</tt>. <tt>!1</tt> represents a lexical block inside the scope
+   <tt>!2</tt>, where <tt>!2</tt> is a
+   <a href="#format_subprograms">subprogram descriptor</a>. This way the
+   location information attached to the intrinsics indicates that the
+   variable <tt>X</tt> is declared at line number 2 at a function level scope in
+   function <tt>foo</tt>.</p>
+
+<p>Now lets take another example.</p>
+
+<div class="doc_code">
+<pre>
+call void @llvm.dbg.declare({ }* %2, metadata !12), !dbg !14
+</pre>
+</div>
+
+<p>The second intrinsic
+   <tt>%<a href="#format_common_declare">llvm.dbg.declare</a></tt>
+   encodes debugging information for variable <tt>Z</tt>. The metadata 
+   <tt>!dbg !14</tt> attached to the intrinsic provides scope information for
+   the variable <tt>Z</tt>.</p>
+
+<div class="doc_code">
+<pre>
+!13 = metadata !{i32 458763, metadata !1}; [DW_TAG_lexical_block ]
+!14 = metadata !{i32 5, i32 9, metadata !13, null}
+</pre>
+</div>
+
+<p>Here <tt>!14</tt> indicates that <tt>Z</tt> is declaread at line number 5 and
+   column number 9 inside of lexical scope <tt>!13</tt>. The lexical scope
+   itself resides inside of lexical scope <tt>!1</tt> described above.</p>
+
+<p>The scope information attached with each instruction provides a
+   straightforward way to find instructions covered by a scope.</p>
 
 </div>
 
@@ -1813,7 +1718,7 @@ enum Trees {
 
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
   <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2009-11-17 14:13:59 +0100 (Tue, 17 Nov 2009) $
+  Last modified: $Date: 2009-12-01 01:59:58 +0100 (Tue, 01 Dec 2009) $
 </address>
 
 </body>
diff --git a/docs/tutorial/index.html b/docs/tutorial/index.html
index bfaafe7265f3..250b533f3f8a 100644
--- a/docs/tutorial/index.html
+++ b/docs/tutorial/index.html
@@ -15,16 +15,6 @@
 <div class="doc_title"> LLVM Tutorial: Table of Contents </div>
 
 <ol>
-  <li><!--<a href="Introduction.html">-->An Introduction to LLVM: Basic Concepts and Design</li>
-  <li>Simple JIT Tutorials
-    <ol>
-      <li><a href="JITTutorial1.html">A First Function</a></li>
-      <li><a href="JITTutorial2.html">A More Complicated Function</a></li>
-      <li><!--<a href="Tutorial3.html">-->Running Optimizations</li>
-      <li><!--<a href="Tutorial4.html">-->Reading and Writing Bitcode</li>
-      <li><!--<a href="Tutorial5.html">-->Invoking the JIT</li>
-    </ol>
-  </li>
   <li>Kaleidoscope: Implementing a Language with LLVM
   <ol>
     <li><a href="LangImpl1.html">Tutorial Introduction and the Lexer</a></li>