similar to: LLVM ORC JIT API

Unfortunately, I did not use ORC JIT’s C API, so at this point it would be helpful if you could compose an example that reproduces the problem. Could you extract the example from your code and give a link to it? gist/pastebin/whatever else would be sufficient. Also, which OS and which version of LLVM do you use? > On 14. Mar 2018, at 10:17, Wycliff Bironga <wycliffb at gmail.com> wrote:

Hello, I've been trying to use LLVM's Orc JIT from C API for a few days and i can't get it to work, I'm kind of annoyed for the lack of documentation examples for the C API. Here's my code: https://hasteb.in/ohexiweb.cpp I compile it using clang `llvm-config --cflags --ldflags --libs all` main.c -o main -g -rdynamic And it ends up segfaulting at the line where it calls

Hi All, In the interests of improving visibility into ORC JIT development I'm going to try writing weekly status updates for the community. I hope they will provide insight into the design and state of development of LLVM's JIT APIs, as well as serving as a convenient space for discussions among LLVM's large and growing community of JIT API users. The length and detail will vary

Hi All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying

Hi Lang, thanks for announcing. Would be great if you could send another short notice as soon as the actual patch exists. Best, Stefan Am 24.05.16 um 23:06 schrieb Lang Hames via llvm-dev: > Hi All, > > I'm going to be making some API breaking changes to the ORC APIs, and > to the RuntimeDyld class (which underlies MCJIT). The changes may > affect MCJIT clients but are unlikely

Hi Stefan, Thanks for your reply. I tried running my simple example on Linux using lli and it does work fine. So I think the best long-term solution is to migrate my code to the new lazy orc jit. Unfortunately, even the simplest example does not work on Windows: int main() { return 0; } This is the output: JITDylib "<main>" (ES: 0x000001b6e4ad3670): Search order: [

Hi, I am developing an application that uses the ORC api to JIT compile C++ code using Clang. So far I have done most of the work on Windows, where it now mostly works as expected. However, when I tried to run my application on Linux I ran into some problems. The problem I ran into is that symbols for jitted inline functions cannot be resolved. Both LLVM and Clang are checked out with latest

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero.

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol

Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > When writing a JIT compiler using LLVM, as I understand it, you can use two > alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would > it be accurate to say that if you want eager compilation - always compile > an entire module upfront - you should use MCJIT? +lang. My understanding is that

When writing a JIT compiler using LLVM, as I understand it, you can use two alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would it be accurate to say that if you want eager compilation - always compile an entire module upfront - you should use MCJIT? -------------- next part -------------- An HTML attachment was scrubbed... URL:

At the moment, neither the example code in the slides PDF, nor that in the new kaleidoscope tutorial, successfully compiles against the current version of ORC (in LLVM 8.0.0). Presumably because this is because ORC has changed since they were written. Is there any example code that works with the current version of ORC? -------------- next part -------------- An HTML attachment was scrubbed...

Hi All, I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review! As described in my last email, this commit breaks the OrcJIT library

Hi, I’m wondering if it’s possible to debug code JIT’ed with the newer ORC JIT. The LLVM documentation has a page at llvm.org/docs/DebuggingJITedCode.html <http://llvm.org/docs/DebuggingJITedCode.html> showing an example of using gdb to debug MCJIT’ed code, but has no mention of ORC JIT. From searching around online I’ve gotten the impression that ORC JIT does *not* support providing

Right, but is there any known use case where Orc's flexibility allows something to be done that couldn't be with MCJIT, apart from lazy compilation? On Wed, Mar 30, 2016 at 12:19 AM, Justin Bogner <mail at justinbogner.com> wrote: > Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > > When writing a JIT compiler using LLVM, as I understand it, you

Hi, I am trying out ORC v2 and facing some problems. I am using LLVM 8.0.1. I updated my ORC v1 implementation from 6.0 to 8.0 based on Kaleidoscope example (i.e. using Legacy classes) and that works fine. Now I am trying out ORC v2 apis, based on https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h. I have got it to compile and build.

Thanks Praveen. Is it suitable for LLVM 7.0.1 ? Apart from flexibility, do we see any compile time improvements as well with ORC? On Sun, Jun 30, 2019 at 12:31 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > MCJIT hopefully will be removed in subsequent releases. I think the last > release version is more suitable. > > On Sun, 30 Jun 2019 at 11:45, Ashok

yeah i m concerned about jit compilation time.. On Sun, Jun 30, 2019 at 12:57 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Yes I think so.. Could you please tell me in which context (compile time > improvement)? That is whether you are interested in knowing whether having > ORC instead of MCJIT, will increase your LLVM Build time or you are > concerned