similar to: Current status of ORC

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, I am trying to run the toy example provided on http://llvm.org/docs/tutorial/BuildingAJIT1.html. However, I am running into a file not found error for llvm/ExecutionEngine/Orc/Core.h. Meanwhile other llvm headers seem to link properly. Can someone help me out, please? Thanks in advance. Sincerely, Anshil Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Yafei, First 2 chapters of the tutorial is up-to-date with ORC v2 APIs. I hope nothing changed in docs and code. Did you got compilation errors? On Thu, 19 Sep 2019 at 00:47, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang for JIT things > > On Tue, Sep 17, 2019 at 7:01 PM Yafei Liu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

Hi all, I am following the LLVM JIT tutorial API based on: https://llvm.org/docs/tutorial/BuildingAJIT1.html I have 2 independent questions: 1. The tutorial mentions that "*will defer compilation of the module until any of its definitions is looked up*". Does that mean to force eager compilation, i have to keep track of all functions added to the Module and do a lookup? I want the

For example, the illustrate part says "ES.getMainJITDylib().setGenerator" while the full code list says "ES.getMainJITDylib().addGenerator", I guess the API is changed, the tutorial part is up to date while the full code list leaves to the old version. On Thu, Sep 19, 2019 at 10:51 AM Yafei Liu <yfliu at mobvoi.com> wrote: > Yes, the function type mismatch, just copy

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

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 Alex Correction : Kaleidoscope chapter 1 & 2 are up-to-date. But chapter 3..5 are not. On Wed, 15 May 2019 at 23:22, Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Alex > Sorry for late reply > > The New ORC APIs support concurrent compilation. > I'm not aware of any migration guide to ORC v2 from v1. But there is a > in-tree classes called

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 all, I am using LLVM for JIT use-case and compile functions on the fly. I want to "free" the modules after some time and reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar

Hi, We are making the move from legacy JIT (llvm-3.5.x) to ORC JIT and I am looking to recompile (and re-link) functions at runtime for an ARM platform (Odroid XU3) . I looked at OrcLazyJIT.cpp as a starting point. However, after going through the code, it appears that the createCompileCallbackMgr (llvm-3.8.0) / createLocalCompileCallbackManager (llvm-git) do not support an ARM triple yet.

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

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:

Hi folks, I'm working on migrating a JIT compiler from the old ORCv1 JIT APIs to the newer ORCv2 ones and am having some trouble getting the code from chapter 1 of the "Building a JIT" [1] tutorial working properly. I have previously walked through the "My First Langauge" [2] tutorial and that went smoothly using the provided JIT class, but using the one from the JIT

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx;

In the Tutorial of the JIT https://llvm.org/docs/tutorial/BuildingAJIT1.html, illustrations and the full code listing are not the same, and the full code listing will not compile, this will make a lot of trouble to beginners since the JIT API is changing all the time. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Bjoern, I’m a bit worried about taking symbols from modules, because some of the > symbols might change later when the code was compiled with the JIT Symbol names shouldn't change from the moment they're added to the JIT (i.e. after being fully mangled). Consistency of symbol names is a requirement for ORC to work. You could try hooking into the orc::Platform API for this:

Hi Bjoern, Did you see my previous reply? There's no way to do this currently. ORC assumes you know all the symbols, > since you added the modules defining them. > For testing / debugging you can dump the modules to stderr using > ExecutionSession::dump, but that's about it. > Do you want the symbols for diagnostic purposes, or some other reason? Regards, Lang. On Mon, Aug

Hi, For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes: 1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial. 2) Be able to interpret my language in addition to compiling. 3) While compiling, be able to execute arbitrary code at compile time. The simple case will be to

Hi LLVM Developers, I have a query about an LLVM error message that I'm encountering and I hope it's appropriate to post to this mailing list about it. Postgres can be built with LLVM-based JIT support. I find that when running on Linux (RHEL8) on IBM Z hardware, using LLVM8+, I'm seeing many instances of the following LLVM error message appearing in the Postgres server log: ORC