similar to: Inlining with the ORC JIT

Hello everyone, Is fully relocatable/position-independent JITted code on the horizon or currently possible with LLVM? I’ve written a Common Lisp compiler (currently called Clasp: https://github.com/drmeister/clasp) in C++ that uses LLVM as the backend and interoperates with C++. It uses copying garbage collection via the Memory Pool System (MPS) garbage collector by Ravenbrook. This garbage

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

I’m developing a Common Lisp compiler for OS X and Linux that uses LLVM as its backend and interoperates with C++. It’s at: github.com/drmeister/clang I need to compile one C++ source file containing small, intrinsic functions into an LLVM-IR bitcode file and link it with bitcode generated by my compiler running LLVM3.6.1. I have been unable to do this for more than a year and I was hoping

I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save them to

Hello, I wonder if someone would know what is going on below. All of a sudden I’m getting this assertion thrown: Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/meister/Development/externals-clasp/llvm36/lib/IR/Value.cpp, line 345. It’s happening when

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

I forgot to mention this in my initial email. The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c The date on the commit is: Date: Fri Sep 26 12:34:06 2014 Also: Today I grabbed the ToT llvm/clang/clang-extra-tools and I’m working on getting my code to be compatible with it. I can switch back and forth between the current ToT llvm and the old one. Thanks,

This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad. https://gist.github.com/drmeister/7a35046f666826206973 Compare line 646 of the file above to the one that I just posted. > https://gist.github.com/drmeister/b97dec956c6ee9ffeb75 The first one

Logan, How would I dump the object file generated by the JIT compiler pipeline? Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk. I’m have code to generate object files for AOT compilation - is it done the same way? Best, .Chris. On Apr 12, 2015, at 2:27 PM, Logan Chien

I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24). I recompiled debug versions of llvm, clang and my code. I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?). The updated file that

Hi All, The initializer patch review at https://reviews.llvm.org/D74300 has been updated. The new version contains a MachOPlatform implementation that demonstrates how Platforms and ObjectLinkingLayer::Plugins can work together to implement platform specific initialization. In this case, the MachOPlatform installs a plugin that scans objects for __objc_classlist and __objc_selref sections and

Thank you. I found a partial answer to the problem (1), namely “how to run Clang compiled with LLVM3.6.1 on OS X Yosemite/Xcode6.4" It’s a combination of -isysroot and -resource-dir I’m using these compiler options: "/Users/meister/Development/externals-clasp/build/release/bin/clang" -v \ -resource-dir

I switched my Common Lisp compiler to use MCJIT on the weekend and ran into a weird problem compiling one particular function. It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when calling processFDE. The weird part is that the function does not appear to do anything special and I've whittled it down to the minimum size that still causes the crash. If I remove even one

Hi Christian, Thanks for sharing this. Yaron Keren has been investigating some problems in the EH frame registration code recently, and I think this may be related. It at least sounds similar to the type of variations in behavior based on code size that Yaron was seeing. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of

One other thing that may or may not illuminate the situation. When I run under gdb (on OS X 10.8.3 this is an ancient version of gdb 6.3.5 - but it works with clang compiled C++ code) I get the following error when I try to list a line in dwarf1.lsp: Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle] (gdb)

Correct or no I don't know, but this change will affect all x86-64 targets including Linux and Windows as getMaxStubSize() is called from the ELF linker as well as the Mach-O linker. 2013/10/15 Christian Schafmeister <chris.schaf at verizon.net> > > With the help of iain at codesourcery.com and andrew.kaylor at intel.com we > tracked the problem down to a bad relocation that

Logan, I need to make a correction of the post that preceded this one! I was wrong when I said this: > When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers? The “uwtable” attribute does not disappear! I had

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations:

Hey folks, I'm wrestling with adding DWARF source code file/line information to my generated LLVM-IR from my Common Lisp compiler. I think I'm doing everything properly using the llvm::DIBuilder class - but when I load my Common Lisp application and load a compiled bundle into it I don't seem to be able to access the metadata properly. I can list source lines using "l -f