> > 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
On Fri, 13 May 2005, Alexander Friedman wrote:>>> 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.This looks basically ok. There are minor things (";;" -> ";"), and the commented out code should be removed. I'm concerned that this leaks the buffer created for the file, can you verify that it doesn't?> 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)?Sure, that sounds good. I'd definitely prefer that it be tested before it goes into CVS. Perhaps adding something to llvm/examples would be a good way to go. One suggestion, you might change the API to be something like this: ParseAsmString(const char *, Module *) Where the function parses the string and appends it into the specified module. This would make self-extending code simpler (no need to parse into one module then link into the preexisting one). -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On May 16, Chris Lattner wrote:> I'm concerned that this leaks the buffer created for the file, can you > verify that it doesn't?I can verify that the functionality doesn't change. If the buffer was leaked before, it'll be leaked now. However, in 'Lexer.l', you have the following code: <<EOF>> { /* Make sure to free the internal buffers for flex when we are * done reading our input! */ yy_delete_buffer(YY_CURRENT_BUFFER); return EOF; } Which should take care of it.> > 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)? > > Sure, that sounds good. I'd definitely prefer that it be tested before it > goes into CVS. Perhaps adding something to llvm/examples would be a good > way to go.I made a 'FibInC' example that uses my little c-wrapper (which in turn uses this). I can submit all of those when they are cleaned up (and linking correctly - more on that later).> One suggestion, you might change the API to be something like this: > > ParseAsmString(const char *, Module *) > > Where the function parses the string and appends it into the specified > module. This would make self-extending code simpler (no need to parse > into one module then link into the preexisting one).This seems reasonable, but what happens to the users of the module if it were to be updated - for example, if I load said module in the jit, and then add something to it. About the linking. Is it possible (within the current makefile framework) to create a shared library that (statically) contains some set of llvm libraries (including the JIT, which currenlty only works if building a tool). I wish to be able to do the following, assuming that I named that library LLVM_C gcc -lc -lLLVM_C c_file_using_llvm.c -I<stuff> -L<stuff> I *could* build everything as a shared library, and include everything on the command line that way, but that seems a bit errorprone, not to mention the fact that building everything with PIC takes ~3x longer. -- -Alex
On May 16, Chris Lattner wrote:> > Sure, that sounds good. I'd definitely prefer that it be tested before it > goes into CVS. Perhaps adding something to llvm/examples would be a good > way to go. > > One suggestion, you might change the API to be something like this: > > ParseAsmString(const char *, Module *) > > Where the function parses the string and appends it into the specified > module. This would make self-extending code simpler (no need to parse > into one module then link into the preexisting one).Ok, here is the new and improved patch for parsing asm strings, with the modifiacations you requested. It is now also tested. As for the actuall testing, here is what I have so far: I have a CWrapper, which contains the c/c++ header file that is used both by the wrapper and it's clients, a .cpp file, and a makefile, that depends on another patch i submitted. It builds a large shared object (though the linker complains about linking non-libtool libraries into a shared lib - any ideas on that?). The question is: should this CWrapper go into examples/ or should it be a more integral part of llvm? The .h file would then be in some include/ subdirectory. I also have a little example file that uses the CWrapper, and indirectly tests the asm parser. This should probably be an example, but i'm not sure how to set up the makefile. I'll attach everything for now - let me know what to change. -------------- next part -------------- A non-text attachment was scrubbed... Name: current_cvs.diff Type: application/octet-stream Size: 8906 bytes Desc: cvs URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050518/496410a6/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: interface-example.c Type: application/octet-stream Size: 2496 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050518/496410a6/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: cwrapper.tgz Type: application/octet-stream Size: 1412 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050518/496410a6/attachment-0002.obj> -------------- next part -------------- -- -Alex