In order to support a multithreaded JIT, the LLVM build process must also pull in the pthreads library. This means that there must be autoconf detection for pthreads and all that sort of thing. I struggled for a couple hours just trying to get LLVM to be able to "AutoRegen.sh" on my Debian system, and I was unable to get it working. In Reid's mailing list post, he made it sound like it wouldn't be challenging for him to do it.
I can help here, but I'm unsure what changes you're requesting. I don't think the "all tools" mention in the summary line is valid because clearly not "all tools" need to be multi-threaded. Probably, only the JIT (lli) needs to be multi-threaded. That being the case, I can set up a configure variable containing the -lwhatever option that should be added to the link line and that variable can be used in lli's makefile. *HOWEVER*, I'm really not sure this is wise unless there is consensus that lli should always be a multi-threaded program. Certainly, there's enough problems with multi-threading that this could break many tests. I'd like some other folks to chime in on this before we make this change.
Well, to be more specific, anything that pulls in "ExecutionEngine.h" needs to link the thread library, since the JIT lock is defined in this header file. If the only thing that includes it is the JIT, then that is the only thing that needs it. Well, to be clear, it isn't that lli itself is multithreaded. My patch explicitly makes sure that the JIT executes sequentially. The issue is that currently, LLVM *cannot* execute multithreaded applications. I agree: I don't want to break anyone, but I think there is not much risk in a patch that adds a lock. It seemed to me that Chris thought that the JIT should support threads. I'll try and dig up a mailing list post, and move this discussion there. This reminds me: I need to update my patch...
We need some consensus on whether we link tools that use ExecutionEngine.h (e.g. lli) with libpthread or not. This is the only issue standing in the way of bug 418 and bug 540. Its fine with me. What say others?
Personally I would like to defer that decision to the tool builder. For example, lli should link to pthreads by default (to work with threaded programs), but it should be possible to use the JIT without it. Given your foray into weak thread symbols, this should be very possible. -Chris
Here's what I've done to resolve this situation: 1. Added a configure script test to ensure -lpthread gets added to the end of the link line for all normally built LLVM tools. 2. Written a Mutex class in lib/System that observes the weak symbols and won't call them if they aren't defined (-lpthread isn't linked in). 3. Designed the Mutex class so that additional threading packages can be used if libpthread is not found (no support currently). This means that, by default, all LLVM tools will link against libpthread if it is found at configure time. If not, the Mutex stuff becomes a bunch of no-ops. Similarly, even if libpthread is found, the Mutex class will revert to no-ops on two conditions: (a) the program is not linked with -lpthread and (b) the pthread interface functions all have weak linkage. In the case where (a) holds but (b) does not hold (GCC 4.0.1/Linux at least) you will get link errors. This is the reason why all tools must link against libpthread if it is found. For Win32, there are no alternate threading tools that make sense so we don't run into this issue. The Mutex class on Win32 will be implemented by jeffc using Win32 Critical Sections after I commit the inital version of the code.
Resolved by these patches: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050711/027015.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050711/027016.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050711/027017.html