search for: llvm_c

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

...ow. It seems possible: each library can be built as a .so file individually. Each directory can also be relinked into a single .o file. It seems logical that you could take these .o files and make a .so file :) > 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 ~3...

On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi <geek4civic at gmail.com>wrote: > Anand, > > > I have not tried building llvm-gcc, though, ... > > Please show me "/path/to/config.status --version". > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8': ./config.status --version llvm config.status 2.8 configured by

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

...ach library can be built as a .so file > individually. Each directory can also be relinked into a single .o file. > It seems logical that you could take these .o files and make a .so file :) > > > 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 buildin...

On Thu, 5 May 2005, Alexander Friedman wrote: >>> Does there happen to be a C interface to the jit ? Our scheme impl >>> has a good FFI, but it doesn't do C++. If not, this is no big deal, >>> and i'll just write something myself. >> >> No, but such bindings would be *very useful*. And since there might be >> other people who need them this

...t 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) {" > >...

> So as it stands, one should think of out JIT as something akin to the > early Java JITs: one function at a time and only one compile per > function. This is extremely primative by modern JIT standards, where a > JIT will do profiling, find hot functions and reoptimize them, > reoptimize functions when more information about the call tree is > available, have several levels of

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,

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

Hallo all, I was trying to Build LLVM with the cmake option LLVM_ENABLE_MODULES just out of curiosity. I used the RELEASE_400/final tag. It didn't work as I almost expected. So I'm wondering if the modulemaps aren't maintained anymore? If they aren't maintained anymore, why aren't they removed and that cmake option also removed?