[LLVMdev] Control Flow and Locks when JITing Functions

Chris Lattner 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 mailing list