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/