search for: direct_object_code_emiss

...ue "-filetype=asm", but has more values, as > "-filetype=obj" and "-filetype=dynlib". > > “obj” is very interesting, but it till not supported L There's work in progress to make this work properly, but it's still a while off. See http://wiki.llvm.org/Direct_Object_Code_Emission . -Eli

...use mingw as+ld to build a DLL. Essentially, this is just building a DLL the same way a conventional compiler like llvm-gcc would. Directly emitting a DLL would be a lot of work, although it doesn't require any architectural changes to LLVM; you'd need something like http://wiki.llvm.org/Direct_Object_Code_Emission plus some code to handle linking. -Eli

Hello! I am working with LLVM project to compile for specific processor (xPEC-processor from NetX chip, http://hilscher.com/ ). I have done support of this target successfully! Assembler code can be emitted with debug information. LLVM - great!) But now I am looking for generation of machine code for my target. I have seen, that "llc" has option "-filetype". It has

Hi all, I'd like to be able to write JIT-compiled code to a Windows DLL. I have no idea where to start though. Does LLVM already offer some support for this? Or would it be straightforward to write my own DLL writer (no advanced features needed)? Or maybe I could use an external linker? All help highly appreciated! Cheers, Nicolas -------------- next part -------------- An HTML

Hi all, I've kicked off a new sub-section on the wiki for monitoring/managing llvm-development projects. For example see the Direct Object Code Emission<http://wiki.llvm.org/Direct_Object_Code_Emission> project. Feel free to add projects to the Wishlist on the front page, and add your own active projects as well! someguy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090417/f8fdf0c0/attachment.htm...

...are of this, but I actually prefer the .ll output because it's human-readable, which is great for debugging purposes. I might add a bitcode writer some time, but it's not a high priority for me right now. What I'm really looking forward to is the .o writer, though (http://wiki.llvm.org/Direct_Object_Code_Emission). That will make things *much* easier for Pure users, as they won't have to install the entire LLVM suite any more if all they want to do is batch-compile Pure programs. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.d...

...lib/ExecutionEngine/JIT/JIT.h lib/ExecutionEngine/JIT/JIT.cpp lib/ExecutionEngine/JIT/JITEmitter.cpp lib/ExecutionEngine/JIT/JITDwarfEmitter.h lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp * Modified to use JITCodeEmitter instead of MachineCodeEmitter (i) http://wiki.llvm.org/Direct_Object_Code_Emission -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090529/66c79903/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: JITCodeEmitter.patch Type: applicatio...

...> > "-filetype=obj" and "-filetype=dynlib". > > > > > > ?obj? is very interesting, but it till not supported L > > > > There's work in progress to make this work properly, but it's still a > > while off. See http://wiki.llvm.org/Direct_Object_Code_Emission . > > > Hi, > > We are "short circuiting" alot of this work in order to hopefully get basic > working ELF and COFF writers into the next release of LLVM. Alot of the DOCE > work is toward a longer goal of providing linkers for LLVM. > It is best to talk to Chri...

On Wed, Jul 1, 2009 at 9:07 AM, Merkulov Aleksey<steel1.0 at mail.ru> wrote: > Hello!  Working with LLVM JIT-compiler I found a small bug and I'd like to correct it.  Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" I'm working on a patch to fix this, although I've heard DOE may change the MachineCodeEmitter interface

Hello! Working with LLVM JIT-compiler I found a small bug and I'd like to correct it. Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" This error emerges because the test creates big static array. Global variables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation

Before we get too far into this, I'd like to point out that there's a ready solution for the problem of the AsmPrinter being slow: Bitcode. If you want IR reading and writing to be fast, you should consider bitcode files rather than assembly (text) files anyway. Bitcode is smaller and faster. And the API is similar, so it's usually easy to change from assembly to bitcode.