similar to: [LLVMdev] Calling LLVM IRbuilder from the LLVM JIT compiler

Hello, A friend and I am making a parser generator and in order to streamline the language development process, we were going to make the LLVM IR builder directly accessible using the LLVM Assembly language as a scripting language to generate the code. I had read somewhere on this list that the JIT compiler can execute native code using function pointers. My questions are these: What kind of

Hello OvermindDL1, We are implementing an extensible language. That's one where you can add commands and constructs to the language without having to recompile the parser. We want compilation of the parser in order to "freeze" it but only as an option. One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template

----- Original Message ---- > From: Eli Friedman <eli.friedman at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Monday, August 31, 2009 3:49:01 PM > Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the JIT > > On Mon, Aug 31, 2009 at 12:17 PM, Samuel

Hi Sam, Thanks for your reply. I am implementing my research (http://www.it.usyd.edu.au/~suri/Detecting%20Buffer%20Over.pdf), a translation of LLVM to a simple non-deterministic language to detect buffer overflows. It involves (1) printing a control flow graph of basic blocks of a function (easily done) (2) translating each llvm statement to a corresponding data flow language (needs ASTs to

On Mon, Aug 31, 2009 at 6:23 PM, Samuel Crow<samuraileumas at yahoo.com> wrote: > If you're wondering why we're doing an interpreted PEG parser generator rather than Boost Spirit 2.x, it's because we need it to be easier to debug the parser.  Once the parser is debugged it can be fed into a compiled parser generator and "frozen" into stand-alone parser code. You do

Hello Anton, Our main.bc was generated with the following command line: llvm-g++ -Illvm\include -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -c -emit-llvm -omain.bc main.cpp The amos.bc file was generated by our experimental llvm-peg parser generator whose internal workings are assembled internally using LLVM Assembly. The parser generator links a C++ library bitcode with C bindings called

Hi again, My point is that your code could not be written in C++ at this time because the only complete compiler for C++ is LLVM-GCC. It will do little endian optimizations on your x86 box and make the resultant bitcode file not work on the ARM processor. It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. Also the FAQ also

Hello again, My partner and I am modifying a PEG parser generator to produce LLVM bitcode from a version of a parsing expression grammar that takes LLVM Assembly as code. It accepts external libraries in its current state so we are writing an external library in C++ using C bindings for the linkage. Trying to get it to link is proving to be more challenging than expected. My partner is trying

Hello LLVM list, I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link

On Mon, Aug 31, 2009 at 12:17 PM, Samuel Crow<samuraileumas at yahoo.com> wrote: > Hello, > > My partner and I am making a small app needs to access a C++ library from the LLVM 2.5 JIT.  We've made sure that there are no classes and have put 'extern "c"' in front of the functions we need to access.  In order to make this work, we seem to need to have a bitcode

Hello everybody, I don't quite understand how the proposed regex library works but I know that PEG parser generators use a super-set of regex functionality to define their parsers. There's also a nice one on Google code called YARDparser that uses templates based on PEGs to generate efficient recursive-decent parsers. Furthermore, my partner and I am working on an interpreter for PEG

Hello, My partner and I am making a small app needs to access a C++ library from the LLVM 2.5 JIT. We've made sure that there are no classes and have put 'extern "c"' in front of the functions we need to access. In order to make this work, we seem to need to have a bitcode version of libstdc++ so we can avoid writing our own implementations of std::string and std::vector.

Hello Surinder, The existing hand-written parser is callable from almost anywhere so the only reason you'd need to have a parser for it would be to extend it. Originally it was written using Flex and Bison but Chris Lattner rewrote it from scratch to catch more errors at the parsing stage. The only feature I've found to be missing from the existing LLVM-AS utility was an include

On 9 May 2011 20:56, Samuel Crow <samuraileumas at yahoo.com> wrote: > In the past I've worked on a PEG parser generator for any LLVM-based language to use.  One obstacle we ran into when generating LLVM IR assembly was that we'd end up cutting and pasting a list of declarations and aliases into every .ll file that needed to link with the others.  I'd propose that in the

Hello LLVM team, In the past I've worked on a PEG parser generator for any LLVM-based language to use.  One obstacle we ran into when generating LLVM IR assembly was that we'd end up cutting and pasting a list of declarations and aliases into every .ll file that needed to link with the others.  I'd propose that in the Bitcode 3.0 format, that a header definition be added to the IR

On May 2, 2010, at 10:45 AM, Samuel Crow wrote: > Hello LLVM list, > > I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to

Hello, I'm helping to write a parser generator that uses LLVM bitcode as its destination type.  Unlike most parser generators, it's written in C++ and is interpreted.  The "actions" defined in it are to be written in LLVM Assembly. In order to support symbol table lookups, there is a function call to a C++ library, saved as bitcode and loaded to a module at startup, that must

I don't think I quite understand this... suppose for example you're trying to use an LLVM-based toolchain running on an x86 PC to write code for a device that uses an ARM processor in big endian mode, so you tell the LLVM code generator "generate code for ARM, big endian"... are you saying the optimizer will actually assume the target device is little endian because the

On Tue, Sep 1, 2009 at 4:53 AM, Samuel Crow<samuraileumas at yahoo.com> wrote: > We're using the LLVM Value * class functions to box and unbox values and functions for our stack.  The stack needs to be able to take indexing without changing the stack pointer so we're using a std::vector for that.  The std::string section would be a lot easier to replace than the two I just

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function