[LLVMdev] LLVM and threading

Keppler, Dave dkeppler at mitre.org
Wed Aug 18 15:54:03 PDT 2010


>-----Original Message-----
>From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
>Behalf Of Martin C. Martin
>Sent: Wednesday, August 18, 2010 5:09 PM
>To: llvmdev at cs.uiuc.edu
>Subject: [LLVMdev] LLVM and threading
>
>Hi all,
>
>
>
>I'd like to run LLVM in a threaded application, where different threads will
>be compiling separate, unrelated code.  I'm compiling using the JIT so I can
>execute the code as soon as it's compiled.
>
>
>
>How should I use LLVM?  Should I create an ExecutionEngine for each thread,
>or only a single, global instance?
>
>
>
>I noticed that JIT::getPointerToFunction() contains:
>
>
>
>  MutexGuard locked(lock);
>
>
>
>and it seems to hold the lock until the method returns.  Does this mean that
>lazy compilation will be serialized?  Would non-lazy compilation be any
>better?  Can compilation be done in parallel by different threads?
>

Yes, because of that lock a single JIT can only be compiling in one thread at a time.  If you want to allow concurrent compiles (to *different* functions), you will have to instantiated multiple JITs.  However, if you go that route, the code that each of the independent JITs compiles won't be able to see anything done by the others since each ExecutionEngine maintains an independent global mapping.  It is possible to rig up a message passing system between JITs to keep their global maps in sync, but that introduces more cases where serialization could happen so you have to be careful to keep those to a minimum.  I've only tried this with the lazy JIT, but I was able to get something similar to what you want to function.

- Dave




More information about the llvm-dev mailing list