search for: parseasmstr

...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...

...s 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 le...

...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...

..., 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 a...

...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). cool, ok. >> 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...

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

> 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