[LLVMdev] Questions on llvm and jit

Shasank Chavan shanko_chavano at hotmail.com
Tue Mar 23 13:44:50 PDT 2010


Hi.  I have more questions regarding llvm and using it as a jit for our purposes.  Also, let me confess that I haven't actually used llvm yet (I'm still prototyping using gnu's libjit).  Some of the issues that have come up from that work so far leads to me these questions:

 

1) We intend to use llvm as a jit in our expression compiler at compile-time only.  At runtime, the x86 code generated from the bitcode compiler will be packed and sent to our runtime facility for execution.  This implies a need to fixup things like external function calls made in the function we generated at compile-time.  So suppose a call to "memcpy" is made in our function F.  The target address for memcpy will need to fixed up at runtime in the x86 code in memory to point to the actual memcpy available on the system.  Obviously we may have problems if memcpy is bound to a different load module (i.e. c runtime), so we may instead fix up the call to point to a wrapper call that's bounded to the app.  The question is, is it possible to walk through the x86 instructions in search for "call" instructions to then fix up the target?  Does llvm have a facility to walk through the actual machine code instructions to do this?  

 

2) Similarly to (1), any external calls made by llvm (e.g. calls to intrinsic functions) will either need to be fixed up (as discussed in (1)) or prevented all-together.  Is there a way to inline all intrinsic calls so that no calls are made other than those purposefully inserted by me.  Similarly, if a branch table is generated for a switch statement, where in memory will this sit relative to the generated x86 code for the function?  Will it be possible to copy both the function and the jump table together into our memory buffer for packing and shipping to our runtime facility?  Will there be wasted space?  Clearly the location of the jump table is relevent in terms of ensuring that the branch target offsets are correct within the function, and for that reason this all matters.

 

3) I noticed with libjit that the reg-allocator and alias analysis (assuming this exists in libjit) is not the best.  I wonder if llvm will have a problem.  If I make the appropriate llvm calls to redundandly load an integer of a pointer several times (e.g. (goo == *a) .... ....  (foo == *a)), will llvm make every effort to reusue the temp created to store *a initially in the second reference?  I tried this out with the llvm demo, and the C code generated automatically created a temp for the first load, and then reused that temp in the secondary reference.  I however would not be making such calls - I instead would probably generate the memory reference twice, and expect llvm to optimize this.  Is my expectation correct?

 

Thanks in advance for answering these questions.

 

- Shasank
 		 	   		  
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100323/1212ad41/attachment.html>


More information about the llvm-dev mailing list