From 01eba397936941f35dfb0995beace7ed03b847f2 Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Fri, 29 Jan 2010 19:10:38 +0000 Subject: [PATCH] Belatedly document r85295 and r85330. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94825 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ProgrammersManual.html | 35 ++++++++++++++++++++++++++++++++--- docs/ReleaseNotes.html | 6 +++++- 2 files changed, 37 insertions(+), 4 deletions(-) diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index 7845d997b62..a37eca2cb8a 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -150,6 +150,7 @@ with another Value
  • Ending execution with llvm_shutdown()
  • Lazy initialization with ManagedStatic
  • Achieving Isolation with LLVMContext
    • +
  • Threads and the JIT
    • @@ -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 will 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 care +must be taken to ensure that side exits and the like do not accidentally +result in concurrent LLVM API calls.

    @@ -2485,6 +2486,34 @@ isolation is not a concern.

    + +
    + Threads and the JIT +
    + +
    +

    +LLVM's "eager" JIT compiler is safe to use in threaded programs. Multiple +threads can call ExecutionEngine::getPointerToFunction() or +ExecutionEngine::runFunction() 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 LLVMContext 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 modifies the IR by adding +CallbackVHs). Another way is to only +call getPointerToFunction() from the LLVMContext's thread. +

    + +

    When the JIT is configured to compile lazily (using +ExecutionEngine::DisableLazyCompilation(false)), there is currently a +race condition 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. +

    +
    +
    Advanced Topics diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index b373e9f14c3..c960f555ee6 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -462,7 +462,11 @@ release includes a few major enhancements and additions to the optimizers:

      -
    • ...
      • +
    • The JIT now defaults +to compiling eagerly to avoid a race condition in the lazy JIT. +Clients that still want the lazy JIT can switch it on by calling +ExecutionEngine::DisableLazyCompilation(false).
    -- 2.11.0