Update LLVM to r96341.

1 files changed, 35 insertions, 6 deletions

diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html
index 80a5db0..df4366a 100644
--- a/docs/ProgrammersManual.html
+++ b/docs/ProgrammersManual.html
@@ -150,6 +150,7 @@ with another <tt>Value</tt></a> </li>
     <li><a href="#shutdown">Ending execution with <tt>llvm_shutdown()</tt></a></li>
     <li><a href="#managedstatic">Lazy initialization with <tt>ManagedStatic</tt></a></li>
     <li><a href="#llvmcontext">Achieving Isolation with <tt>LLVMContext</tt></a></li>
+    <li><a href="#jitthreading">Threads and the JIT</a></li>
   </ul>
   </li>
 
@@ -2386,9 +2387,9 @@ failure of the initialization.  Failure typically indicates that your copy of
 LLVM was built without multithreading support, typically because GCC atomic
 intrinsics were not found in your system compiler.  In this case, the LLVM API
 will not be safe for concurrent calls.  However, it <em>will</em> be safe for
-hosting threaded applications in the JIT, though care must be taken to ensure
-that side exits and the like do not accidentally result in concurrent LLVM API
-calls.
+hosting threaded applications in the JIT, though <a href="#jitthreading">care
+must be taken</a> to ensure that side exits and the like do not accidentally
+result in concurrent LLVM API calls.
 </p>
 </div>
 
@@ -2485,6 +2486,34 @@ isolation is not a concern.
 </p>
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="jitthreading">Threads and the JIT</a>
+</div>
+
+<div class="doc_text">
+<p>
+LLVM's "eager" JIT compiler is safe to use in threaded programs.  Multiple
+threads can call <tt>ExecutionEngine::getPointerToFunction()</tt> or
+<tt>ExecutionEngine::runFunction()</tt> concurrently, and multiple threads can
+run code output by the JIT concurrently.  The user must still ensure that only
+one thread accesses IR in a given <tt>LLVMContext</tt> while another thread
+might be modifying it.  One way to do that is to always hold the JIT lock while
+accessing IR outside the JIT (the JIT <em>modifies</em> the IR by adding
+<tt>CallbackVH</tt>s).  Another way is to only
+call <tt>getPointerToFunction()</tt> from the <tt>LLVMContext</tt>'s thread.
+</p>
+
+<p>When the JIT is configured to compile lazily (using
+<tt>ExecutionEngine::DisableLazyCompilation(false)</tt>), there is currently a
+<a href="http://llvm.org/bugs/show_bug.cgi?id=5184">race condition</a> in
+updating call sites after a function is lazily-jitted.  It's still possible to
+use the lazy JIT in a threaded program if you ensure that only one thread at a
+time can call any particular lazy stub and that the JIT lock guards any IR
+access, but we suggest using only the eager JIT in threaded programs.
+</p>
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="advanced">Advanced Topics</a>
@@ -2970,9 +2999,9 @@ the <tt>lib/VMCore</tt> directory.</p>
 <div class="doc_text">
 
 <ul>
-  <li><tt>bool isInteger() const</tt>: Returns true for any integer type.</li>
+  <li><tt>bool isIntegerTy() const</tt>: Returns true for any integer type.</li>
 
-  <li><tt>bool isFloatingPoint()</tt>: Return true if this is one of the two
+  <li><tt>bool isFloatingPointTy()</tt>: Return true if this is one of the five
   floating point types.</li>
 
   <li><tt>bool isAbstract()</tt>: Return true if the type is abstract (contains
@@ -3892,7 +3921,7 @@ arguments. An argument has a pointer to the parent Function.</p>
   <a href="mailto:dhurjati@cs.uiuc.edu">Dinakar Dhurjati</a> and
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
   <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2010-01-05 19:24:00 +0100 (Tue, 05 Jan 2010) $
+  Last modified: $Date: 2010-02-15 17:12:20 +0100 (Mon, 15 Feb 2010) $
 </address>
 
 </body>