On May 16, Chris Lattner wrote:> On Mon, 16 May 2005, Alexander Friedman wrote: > > Would it be possible (ie, relatively straitforward) to do the > > following: Take the code in module A, compile it with the JIT (since > > we cannot make libraries in Windows), and save the resulting binary > > goo in some file. Later (in a different instance of the runtime), with > > some much smaller sized loader, read in the file and link that code to > > the runtime. The platforms we care about this working on is the x86, > > ppc, and sparc v9. > > Yes, this would be straight-forward. The output of the code generator is > a bunch of bytes of machine code and relocations to perform on it. This > is exactly what you would need to do this.It looks like I am going to wind up writing something like this. Will you guys accept a patch? It seems like the result will be a much-simplified version of the JIT/JIT.cpp and JIT/JITEmitter.cpp, as well as some utility to write the code and relocations into a file. There will also need to be a loader, which will depend on as little of the framework as possible. This seems fairly usefull - it breaks the reliance on the system assembler for dynamic systems. What do you guys think? -- -Alex
Alexander, Yes, a patch like that would be accepted. Fewer dependencies = good :) Some notes on doing this: (1) Please make sure you use the std c++ iostream libraries for doing I/O. No native calls (we end up with portability problems). If you need something that must be ported, please add it to lib/System (2) You should also use the sys::Path class (include/llvm/System/Path.h) for handling paths in a platform independent way. (3) Your patch should be an incremental add to LLVM, not removing any existing JIT functionality. If it is warranted, consider creating a bugzilla bug to track this as it makes our life easier for release notes, patch collection, etc. Otherwise, just send the patch to this list. Thanks, Reid. On Thu, 2005-05-26 at 20:04 -0400, Alexander Friedman wrote:> On May 16, Chris Lattner wrote: > > On Mon, 16 May 2005, Alexander Friedman wrote: > > > Would it be possible (ie, relatively straitforward) to do the > > > following: Take the code in module A, compile it with the JIT (since > > > we cannot make libraries in Windows), and save the resulting binary > > > goo in some file. Later (in a different instance of the runtime), with > > > some much smaller sized loader, read in the file and link that code to > > > the runtime. The platforms we care about this working on is the x86, > > > ppc, and sparc v9. > > > > Yes, this would be straight-forward. The output of the code generator is > > a bunch of bytes of machine code and relocations to perform on it. This > > is exactly what you would need to do this. > > It looks like I am going to wind up writing something like this. Will > you guys accept a patch? > > It seems like the result will be a much-simplified version of the > JIT/JIT.cpp and JIT/JITEmitter.cpp, as well as some utility to write > the code and relocations into a file. > > There will also need to be a loader, which will depend on as little of > the framework as possible. > > This seems fairly usefull - it breaks the reliance on the system > assembler for dynamic systems. What do you guys think? >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050526/345543f2/attachment.sig>
On May 26, Reid Spencer wrote:> Alexander, > > Yes, a patch like that would be accepted. Fewer dependencies = good :) > > Some notes on doing this: > > (1) Please make sure you use the std c++ iostream libraries for doing > I/O. No native calls (we end up with portability problems). If you need > something that must be ported, please add it to lib/SystemSure. What counts as a 'native call' ? :)> (2) You should also use the sys::Path class (include/llvm/System/Path.h) > for handling paths in a platform independent way. > > (3) Your patch should be an incremental add to LLVM, not removing any > existing JIT functionality.I was actually going to make something orthogonal to the JIT. It would not support nearly as much functionality as the JIT (though it would have similar code). Here is a very loose use case - does this seem reasonable? **** #include modulecompiler #include module_loader char * countdown_function "int %countdown (int %AnArg) {\n" " %result = call fastcc int %foo-int (int %AnArg) \n" " ret int %result\n" "}\n" "fastcc int %foo-int (int %AnArg) {\n" "EntryBlock:\n" " %cond = setle int %AnArg, 2\n" " br bool %cond, label %return, label %recur\n" "return:\n" " ret int 1\n" "recur:\n" " %sub1 = sub int %AnArg, 1\n" " %result = tail call fastcc int %foo-int (int %sub1)\n" " ret int %result\n" "}\n" Module * M = parseAsmText(countdown_function); RelocatableCode * code = compileModule(M); WriteRelocatableCodeToFile (code,"file"); // now load. This part should be as light as possible - that is, very small // in size of the compiled binary. The resulting "module" is fairly static, not like // standard llvm modules. // should be able to get pointers to functions and change value of // global pointers. NativeModule * mod = ReadAndRelocateCodeFromFile ("file"); int (* countdown) (int); countdown = (int (*)(int)) GetPointerToFunction("countdown",mod); printf("result of countdown: %d\n", countdown (1000000)); *** There are a few problems that I need some input on. First, I want the loader to be as tiny as possible. So, I don't want to link in VMcore and friends. Is it possible to just link in selected object files instead of entire libraries? Second, there is functionality that the loader needs to have that depends on VMCore, but doesn't actually need it for my purposes. The main thing is the 'relocate' function in each (System)JITInfo.cpp file. I would like to be able to get the correct JITInfo object (really just the function) without having to link in extra stuff, instantiate modules,targets, etc. Ideally this would not require duplicating any code :) How does one go about doing this? -- -Alex