[LLVMdev] Control Flow and Locks when JITing Functions
sabre at nondot.org
Thu Apr 21 10:30:01 PDT 2005
On Thu, 21 Apr 2005, Evan Jones wrote:
> On Apr 21, 2005, at 12:12, Chris Lattner wrote:
>> Ok. Thanks, for forgot about that patch :(
> No problem, since I still don't know how to integrate it cleanly into the
> build system. Platform dependencies are very annoying.
yes, yes they are :)
>> I think it would be more straight-forward to have a single lock that the
>> jit resolver can aquire. Makes sense to me at least
> This is actually what I ended up doing. So now, the lock in "ExecutionEngine"
> is public, and everything involved in the JIT locks it.
> has been rewritten to point to the native function. However, in this case,
> these threads have already called the stub. So the fix is one of:
> A) Hang on to stub -> function mapping indefinitely. (I'm going to try and
> implement this to get my project that is due tomorrow working)
For the short term, that is definitely the right way to go. In the long
term it probably also makes sense. If you want to test a patch that keeps
these around, I would be happy to apply it to CVS (even before the JIT
gets multithread support).
> B) Have the threads wait on a condition in that particular spot. When another
> thread finishes rewriting the stub, it wakes the threads up. These threads
> then go and do some low level hack, like calling the stub again, and
> immediately call the compiled function. This is probably a better solution,
> but it certainly is more complex.
Frankly, I don't know if it's enough of any issue to justify the
> Any other ideas?
Another option is to store the resolved pointer in the stub itself
somewhere. However, I don't think every call goes through the a stub. In
particular, I think that the JIT can compile direct calls to unresolved
functions to be direct calls to the JIT resolver stub. The JIT resolver
then looks at the return address (which is a JIT compiled function) to
figure out what to resolve. PPC forces the use of stubs in most cases due
to short call offsets, so you might not be seeing this.
More information about the llvm-dev