similar to: [LLVMdev] LLI Enhancement

Hey all, In case anyone is interested in using the X86 JIT for stuff, here's a rundown on where it stands. The X86 JIT can currently be used like this: lli -force-interpreter=false foo.bc <args> Until the remaining issues, described below, are fixed, the -force-interpreter switch will default to true. Once things are finished, it will default to false, so lli will automatically

A new and improved C frontend is now available for experimentation. This is a C frontend that is based on the GCC AST representation as opposed to the old frontend which came from the RTL representation (which lost a lot of type information and caused other problems). I am still working on the new front-end, but it is remarkably stable for being so new. If you are interested in playing with it,

On Mon, 3 Apr 2006, Michael McCracken wrote: > the bytecode with lli - I get the following error: > > $ lli -load=/home/mmccrack/linux/lib/libTau.sh leo-inline-300-tau.bc > ERROR: Program used external function > '__llvm_cxxeh_allocate_exception' which could not be resolved! This is most likely because you are trying to link with llvmgcc, not with llvm-g++. Make sure that

On Thu, 24 Feb 2005, xavier wrote: > Hi, > > I have some questions about LLVM > > Since it is available in several and different platforms like Intel x86, > PowerPc and Sparc, how do you handle the differences between these > platforms in your bytecode? For example, Can a bytecode generated under > MacOS run in the LLVM version under Linux x86? How do you handle things

On Thu, 19 Jul 2007, Andy Kitchen wrote: > Hi there, I'm trying to run trivial Objective-C code that uses the > Foundation framework under MacOS X in lli. It seems that the code will > compile and run using llc, however fails to work in lli. Nice! this is a great project, unfortunately, there are some issues here :) I'm CC'ing Marcel, as he has some experience with

Here are a few bits of news about the C frontend: 1. I have ported it to compile and run under linux. On our research machines, it is available here: /home/vadve/lattner/cvs/gcc_install_x86 Note that this C compiler will still generate "64-bit" LLVM files, thus the code will probably not work right if run through the C backend, then compiled on x86. For middle-end

On Wed, 25 Oct 2006, Sarah Thompson wrote: > Is there any way to support calling external libraries from interpreted > code (*not* JITted code) within lli? Sure. > I am looking at the external functions implementation, and it seems just > to wrap back onto its own library, looking up lli_X_... prefixed > functions. It would (for obvious reasons) be incredibly useful not to be >

Hi, I have a large-ish application I'm trying to build with LLVM, so I replaced g++ in the Makefiles with llvm-g++. This appears to work fine when I pass -Wl,-native to generate an ELF executable, but I want to control the inlining threshold it uses, so I am now passing -Wl,-disable-inlining and -Wa,-disable-inlining, and having it generate LLVM bytecode, then running opt -inlining to generate

On Tue, Nov 21, 2006 at 05:33:32PM +0800, Mohd-Hanafiah Abdullah wrote: > Emil: > > I'm using LLVM 1.9 now. When I tried to do what you did I got the > following though: > > $ llvm-g++ -emit-llvm -c x.cpp > $ llvm-link -o=linked.o x.o std/*.o sup/*.o > WARNING: Linking two modules of different target triples! > WARNING: Linking two modules of different target

Evan Cheng wrote: > We always welcome more tests. But it looks like there are two issues > here. > > 1. The autoconf requirement. Is it possible to get one configuration > working without the need for autoconf? > I could make an clamav-config.h that should work if compiled with llvm-gcc. Can I assume <endian.h> exists on all your platforms? [or how else can I detect

On Fri, 11 Mar 2005, Al Stone wrote: > So. I _finally_ got the building and packaging of LLVM and the > GCC FE into a state I'm more or less happy with. As a result, I > uploaded x86 packages into the NEW queue just a little while ago. > Whew. Nice! Thanks a lot Al! -Chris > What this means is that in a few weeks (hard to say how long, > really) the package will be

The previously library-side ‘file_architecture’ API is reimplemented in the daemon, in OCaml. There are some significant differences compared to the C implementation: - The C code used libmagic. That is replaced by calling the ‘file’ command (because that is simpler than using the library). - The C code had extra cases to deal with compressed files. This is not necessary since the

Chris Lattner wrote: >>test for linux / definition of __STDC_LIMIT_MACROS. This will not work, >>since stdint.h is implemented by including inttypes.h, which was already >>included the first time with __STDC_LIMIT_MACROS not defined. I think >>the best solution to this problem is to change DataTypes.h to simply: >> >> #define __STDC_LIMIT_MACROS >>

Hi everyone, Here's an update on what we've been up to and how the LLVM 1.0 release is shaping up. Overall, things are going well, and it looks highly likely that we'll get the release out by the end of the month! Here's the hilights of the last few weeks: 1. John checked in support for building LLVM into multiple different object directories in the Autoconf style. He also

On Fri, 20 Jul 2007, Ralph Corderoy wrote: > I could be missing something, but shouldn't the use of dlsym() be > The authors of dlsym() realised the return value was overloaded AFAICS. Yep, patches welcome :) -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Thu, 26 Oct 2006, Sarah Thompson wrote: > Chris Lattner wrote: >> 3. Best: Find a "foreign function interface" library, and use that to >> interface to native code. >> > This is the only option that's really usable, unfortunately, because I > have no control over what code some potential user might want to model > check. Ok. > I was wondering

On Sat, 2 Sep 2006, Anton Vayvod wrote: > I didn't manage to link my regalloc to lli (I added USEDLIBS to its > makefile). Without it I can't run tests cause they need lli to be built. So > how can I link createMyRegisterAllocator function to lli? Make sure to add it to Codegen/LinkAllCodegenComponents.h. -Chris > On 8/22/06, Anton Vayvod <avayvod at gmail.com> wrote:

Hi, I have some questions about LLVM Since it is available in several and different platforms like Intel x86, PowerPc and Sparc, how do you handle the differences between these platforms in your bytecode? For example, Can a bytecode generated under MacOS run in the LLVM version under Linux x86? How do you handle things like little endian / big endian? How do you handle the difference in

Yes, sorry for not mentioning it. I added that header also Although I suppose that if I am not using Sparc there will be no problem (it's an Itanium 2 machine) Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > I commented this line and it is compiling now: > > > > extern void *malloc ARGS((unsigned)); > >

On Jun 24, 2013, at 4:18 PM, Stefan Teleman <stefan.teleman at gmail.com> wrote: > I'll file the bug about the endian stuff, but we'll also have to have > an <endian.h> in Solaris as well. Do you still have issues after r182419? commit 01ef4f6982451e6a7c00a713d9ae677d3a15d042 Author: Jakob Stoklund Olesen <stoklund at 2pi.dk> Date: Tue May 21 13:36:13 2013