> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function, > etc. > > If kept simple, standardized, and generic, I think it would be very useful > to people (even if incomplete). This would allow others to build on it, > and we could 'ship' it as a standard llvm library.It looks like my interface will look vaguely like this. Functions like "llvm_make_module" will take in text representations of the module. This seems to be the fastest way of getting our scheme implementation to talk to the jit. This requires being able to parse strings. The LLVM 'Parser.h' interface (and implementation) has the built in assumptions that it will always be parsing from the file system. Would you guys accept a patch that makes it more general (ie, parse from file or string)? If so, what's an easy way to do it? Is it possible to have a "FILE" struct backed by a string? FYI, here is a sketch of what the fib example would look like: #include "llvm_c.h" /* Everything takes and recieves void * pointers. This to avoid redefining C++ types. This is the C 'version' of the Fib example, at least in spirit. */ char* fib_function "int %fib (int %AnArg) {" " EntryBlock: " " %cond = setle int AnArg, 2" " branch bool %cond, label return, label recur" " return:" " ret int 1" " recur:" " %sub1 = sub int %AnArg, 1" " %fibx1 = call tail int %fib (int %sub1) " " %sub2 = sub int %AnArg, 2" " %fibx2 = call tail int %fib (int %sub2) " " %result = add int %fibx1, %fibx2" " ret int %result" "}"; void * M = llvm_make_module_from_text (program, "test") ; // now we want to run some optimizations on this thing. // make a pass manager void * PM = llvm_make_pass_manager(); // add 'target data' to module llvm_addPass(PM, make_target_data("jit-lib",M)); llvm_addPass (PM, llvm_createVerifierPass()); // add optimization passes here // addPass (PM, ... ) llvm_run_passes(PM,M); // merge modules - not relevant here // make an execution engine from the module void * JE = llvm_make_jit_engine (M); // get a function pointer by name. If you have several functions with the same // name, you are out of luck int (*fib) (int) = (int (*)(int)) llvm_get_function_pointer(JE,M,"fib"); // the above cast is probably wrong. int result =fib (24); -- -Alex
On Thu, 12 May 2005, Alexander Friedman wrote:>> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function, >> etc. >> >> If kept simple, standardized, and generic, I think it would be very useful >> to people (even if incomplete). This would allow others to build on it, >> and we could 'ship' it as a standard llvm library. > > It looks like my interface will look vaguely like this. Functions like > "llvm_make_module" will take in text representations of the > module. This seems to be the fastest way of getting our scheme > implementation to talk to the jit.ok> This requires being able to parse strings. The LLVM 'Parser.h' interface > (and implementation) has the built in assumptions that it will always be > parsing from the file system. Would you guys accept a patch that makes > it more general (ie, parse from file or string)?Yes, that's a generally useful thing to have, I'd like to see it happen if it doesn't impact the efficiency of the lexer.> If so, what's an easy way to do it? Is it possible to have a "FILE" > struct backed by a string?Hrm, I really don't know. :(> FYI, here is a sketch of what the fib example would look like: > > #include "llvm_c.h" > > /* > Everything takes and recieves void * pointers. This to avoid redefining C++ > types.Makes sense.> This is the C 'version' of the Fib example, at least in spirit. > */ > > char* fib_function > "int %fib (int %AnArg) {" > > " EntryBlock: " > " %cond = setle int AnArg, 2" > " branch bool %cond, label return, label recur" > > " return:" > " ret int 1" > > " recur:" > " %sub1 = sub int %AnArg, 1" > " %fibx1 = call tail int %fib (int %sub1) " > " %sub2 = sub int %AnArg, 2" > " %fibx2 = call tail int %fib (int %sub2) " > " %result = add int %fibx1, %fibx2" > " ret int %result" > "}";Some typeos (branch -> br, 'call tail' -> 'tail call', etc) but general idea makes sense.> void * M = llvm_make_module_from_text (program, "test") ;One of these should be fib_function right? What is the 'test' string?> // now we want to run some optimizations on this thing. > // make a pass manager > void * PM = llvm_make_pass_manager(); > > // add 'target data' to module > llvm_addPass(PM, make_target_data("jit-lib",M)); > > llvm_addPass (PM, llvm_createVerifierPass());I'd suggest using C style llvm_create_verifier_pass consistently, but your call :)> // add optimization passes here > // addPass (PM, ... ) > > llvm_run_passes(PM,M); > > // merge modules - not relevant here > > // make an execution engine from the module > void * JE = llvm_make_jit_engine (M); > > // get a function pointer by name. If you have several functions with the same > // name, you are out of luck > int (*fib) (int) = (int (*)(int)) llvm_get_function_pointer(JE,M,"fib"); > > // the above cast is probably wrong. > > int result =fib (24);Looks good! -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
> > This requires being able to parse strings. The LLVM 'Parser.h' interface > > (and implementation) has the built in assumptions that it will always be > > parsing from the file system. Would you guys accept a patch that makes > > it more general (ie, parse from file or string)? > > Yes, that's a generally useful thing to have, I'd like to see it happen if > it doesn't impact the efficiency of the lexer.Ok, here's a patch. I added a 'parseAsmString' function to the Parser interface. It doesn't seem to break any tests, so parsing files seems to still work ok. I commented out some code/global variables that don't seem to be usefull anymore - feel free to remove those lines completely if they are in fact not. I havn't tested parsing strings yet. My code is extremely simple and *should* work, but we know where that line of thinking leads. Should I submit a test case (it would have to be a C file that links in the parser)?> > void * M = llvm_make_module_from_text (program, "test") ; > > One of these should be fib_function right? What is the 'test' string?In the fib example, the module is named 'test', so I assumed it was usefull for some reason. -------------- next part -------------- A non-text attachment was scrubbed... Name: asm_parser.diff Type: application/octet-stream Size: 9012 bytes Desc: parse asm strings URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050513/8d0e347e/attachment.obj> -------------- next part -------------- -- -Alex