>-----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