search for: f_binari

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Chris Lattner wrote: > Given that we don't guarantee backwards compatibility and prefer to keep > our APIs clean and tidy, why should we take this? I already said that: To make it easier for out-of-tree frontends to support at least the last few LLVM versions. If that's a low priority then don't. I can live with it. Please understand that I don't complain about API breakage

On Aug 25, 2009, at 3:40 PM, Albert Graef wrote: > Albert Graef wrote: >> I understand that. But in this specific case it would be very easy to >> maintain, no? > > FWIW, suggested patch attached. That makes the LLVM 2.5 style > raw_fd_ostream constructor work with the trunk (r80036). Note that > this > just adds a second constructor, existing code will continue to

I'm using the LLVM C++ API to create code on-the-fly for execution. This works fine. But what if I want to save this code to disk, quit, relaunch my app at some later time, reload the previously generated code off disk, and execute it? How can I do that? Can somebody point me to some documentation or examples? Thanks. - Paul

Albert Graef wrote: > I understand that. But in this specific case it would be very easy to > maintain, no? FWIW, suggested patch attached. That makes the LLVM 2.5 style raw_fd_ostream constructor work with the trunk (r80036). Note that this just adds a second constructor, existing code will continue to work as before. I'd be happy to prepare an analogous patch for the 2.6 release

On Aug 25, 2009, at 11:34 PM, Albert Graef wrote: > Chris Lattner wrote: >> Given that we don't guarantee backwards compatibility and prefer to >> keep >> our APIs clean and tidy, why should we take this? > > I already said that: To make it easier for out-of-tree frontends to > support at least the last few LLVM versions. If that's a low priority > then

Hello Everyone, I am trying to create two modules in LLVM, where first module contains the definition of a function, gcd in this example and another module contains a call to this function. My example is based on the following tutorial, with a few changes. http://llvm.org/releases/2.6/docs/tutorial/JITTutorial2.html When I execute the verifier pass on my modules, it complains that the

I have a frontend that generates some LLVM bitcode that needs to be linked with other bitcode (its runtime library), which I generate from C++ source using Clang. If I write the output of my program to disk, link it with llvm-link, and then run it with lli, everything works perfectly. But if I try to perform the linking and running steps in my main program, I get this error during

Yes. It appears that a bad reference to DataLayout was passed to MachineJumpTableInfo::getEntrySize. I'm using LLVM as a pre-compiled Ubuntu package for this work, so I can't do much more in GDB without building from source. Program received signal SIGSEGV, Segmentation fault. 0x00000000007565f0 in llvm::MachineJumpTableInfo::getEntrySize(llvm::DataLayout const&) const () (gdb)

Hi Andy, It looks like you're using LLVM's old JIT, rather than MCJIT? The old JIT has been removed from the mainline, and is no longer supported. I'd recommend building your own copy of LLVM from the development branch (as Reed suggested) where MCJIT is used by default - this may fix your issue. If you want to stick with the precompiled binaries, then you should change: #include

Hi, There: This is the proposal for parallelizing post-ipo stage. See the following for details. I also attach a toy-grade rudimentary implementation. This implementation can be used to illustrate some concepts here. This patch is not going to be committed. Unfortunately, this weekend I will be too busy to read emails. Please do not construe delayed response as being rude :-).