[LLVMdev] Interactions with threads and native code

[Chris Lattner]

On Tue, 8 Feb 2005, Evan Jones wrote:

> On Feb 8, 2005, at 21:36, Chris Lattner wrote:
>> That is correct.  If you try to run threaded programs in the JIT, it might 
>> run into problems if multiple functions need to JIT functions at the same 
>> time.  This should be very simple to deal with, we just haven't had anyone 
>> take up the task yet.  Only the JIT is affected here, not the static code 
>> generator or C backend.
>
> Well, I'll take a look at the JIT code and see if I am up to it. I need to do 
> a project for the parallel processing course I am taking right now anyway, 
> and doing work that is actually useful to someone would be a much better use 
> for my time.

That would be great.  As a first implementation, I would suggest adding a 
lock to the ExecutionEngine class in 
include/llvm/ExecutionEngine/ExecutionEngine.h, locking it when 
particular state is accessed.  Note that the JIT subclasses this in 
lib/ExecutionEngine/JIT/JIT.h, so its accesses should be synchronized as 
well.

The only really tricky thing about this is making the locking portable 
across platforms.  However, I think the 
include/llvm/Support/ThreadSupport.h file should export what you need.

> What about the LLVM interpreter, for situations where there is no JIT? Is it 
> thread-safe?

Yes, I believe it is thread safe.  However, is not widely used and is 
REALLY slow (even for an interpreter).

>>> Does anyone have any thoughts about if or how LLVM should support threads? 
>>> I was thinking that it might be worthwhile to add a few thread primitives 
>>> to the llvm.* collection of instrinsics. Something like llvm.spawn, 
>>> llvm.join, llvm.lock, llvm.unlock, and llvm.cas would be sufficient for my 
>>> purposes.
>> There has definitely been talk about this.  We are slated to get very 
>> low-level primitives for compare&swap and atomic increment.  I can't say 
>> when they will be added (I'm not doing the work myself) but I've been told 
>> it should be soon.
>
> Random related thought: I think it is unfortunate that more processors don't 
> natively support load-linked/store-conditional.

Indeed.  Unfortunately they can't be emulated well on processors that do 
not support them.

>> The other ones are higher level.  There is a balance here between what we 
>> want to express directly in llvm, and what we want defer to native 
>> libraries.  The argument for putting things into LLVM is that it makes it 
>> easier for front-end people to produce portable bytecode files (they don't 
>> have to provide target-specific runtime libraries).  The argument against 
>> is that we only want target- and language-independent capabilities to be 
>> added to LLVM.
>
> I definitely think that some sort of portable support for threads would be 
> very useful. At the very least, adding primitives to libSystem and having 
> some portable way to link to them from the bytecode would likely solve most 
> of the problem.

It's not clear to me that this is something that needs to be implemented 
as instructions or intrinsics in the LLVM representation itself.  To me, 
there would be just as much value defining a standard LLVM runtime library 
for threads that front-ends could choose to link to.  This is similar to 
how the GC support works: only the bare minimum support required for 
pulling references out of the stack is built into LLVM, the rest (e.g. 
the specific GC algorithm being used) is related to a runtime library.

>> LLVM works exactly like a native compiler.  If you call an external 
>> function you have to link to the appropriate (possibly native) library with 
>> -lFOO options.
>
> Ah, I figured it out: lli calls dlopen on the libraries supplied by a command 
> line parameter. The nasty compatibility hacks that are performed on Linux for 
> libpthreads were preventing llvm-gcc from adding the correct parameter to the 
> script file. When I manually added "-load=/lib/tls/libpthread-0.29.so" it 
> worked.

Ok, yes, as you figured out, the JIT is a bit different. :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/