llvm dev - Jul 2007 - [LLVMdev] Forcing JIT of all functions before execution starts

Chris Lattner wrote:
> Check out http://nondot.org/sabre/LLVMNotes
>
>   
  %Size = getelementptr %T* null, int 1
  %SizeI = cast %T* %Size to uint


How incredibly cunning. :-) Thanks for that.


Next stupid question. I've put together a simple coroutine/fibre style 
threading system on top of the Linux setcontext/getcontext stuff, which 
surprisingly enough seems to work *almost* perfectly under the JITted 
environment, with the exception that the JITter doesn't like running in 
anything other than the primary fibre. For example,

#include <stdio.h>
#include "../../mcp/tools/mcp2/mcpapi.h"

void thread1(void *udata)
{
	int i;
	for(i=0; i<10; i++)
	{
		printf("--- thread1: Hello (%d)\n", i);
	}
}

void thread2(void *udata)
{
	int i;
	for(i=0; i<10; i++)
	{
		printf("--- thread2 Hello (%d)\n", i);
	}
}

int main(int argc, char **argv)
{
	printf("--- Running threads serially:\n");
	thread1(0);
	thread2(0);

	printf("--- Running threads in parallel:\n");
	mcp_begin_thread(thread1, 0);
	mcp_begin_thread(thread2, 0);

	printf("--- Waiting for child threads to terminate\n");
	mcp_wait_for_exit();

	printf("--- Bye...\n");
	return 0;
}

works perfectly, because thread1() and thread2() are forced into 
existence before they are referenced by mcp_begin_thread() (i.e. as a 
parameter to makecontext). Commenting out the running threads serially 
section results in a seg fault inside the jitter. Since we have to make 
so many performance compromises in the name of model checking anyway, 
it's no big deal for me to just basically force every function in the 
module to be compiled before execution starts, which should effectively 
mean that the JITter can never execute at run time (and therefore can 
never accidentally be run inside a child thread). What is the 
best/safest way to do this? Is it OK just to enumerate all the functions 
within the module and resolve them to non-lazy function pointers? I 
think in V1.8 just taking the address of a function was enough to cause 
it to be jitted, so something has obviously changed a bit since then.

Thanks,
Sarah

(I have verified that just going through all the Functions in the Module 
and calling getPointerToFunction for each in turn actually seems to work 
-- I just wanted to make sure that this is sensible)

Sarah

On Fri, 27 Jul 2007, Sarah Thompson wrote:
> (I have verified that just going through all the Functions in the Module
> and calling getPointerToFunction for each in turn actually seems to work
> -- I just wanted to make sure that this is sensible)
Yep, that is both sensible and is the recommended approach.  However, the 
JIT should lock itself (using pthreads calls) to prevent itself from dying 
in a multithreaded situation.  If you're using pthreads then you found a 
bug.

One feature you might be interested in is the EE->DisableLazyCompilation() 
method.  This will cause the jit to abort if you ever ask it to do lazy 
compilation.  This is a useful 'assertion' mode if you think your code 
should compile everything ahead of time and want to know if you ever 
forgot something. :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/