similar to: Current ORC API?

Hi Praveen, On Sat, 10 Aug 2019 at 21:05, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Could you please send me your unoptimized and expected optimized code? The default implementation only contains some transformations. It would be helpful to know what you are actually trying. > Optimize Module is just a function object. > You can view the code here:

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.

Nice! Let me try to answer some questions, Before that I have to mention this is ORC version 2 APIs and this is where the project is moving forward. JITDylib is the symbol table, basically for a JIT Symbol it have an associated materializers, (you can think of it like an entity that generate the address for that symbol), Example: compiler are materializers. So to add symbols to your own JIT you

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

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;

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

You can add symbols from Archieve via StaticLibrarySearchGenerator. But it is added recently though On Tue, 27 Aug 2019 at 21:02, Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > I tried it, but I can't able to reproduce it. > > Test Program: > #include <fstream> > int main() > { > std::ifstream stream1, stream2; >

Yes, I confirm. Le ven. 20 déc. 2019 à 19:12, Praveen Velliengiri < praveenvelliengiri at gmail.com> a écrit : > Hi, > Orc v2 is different from the internal structure then Orc v1 not just in > API level. > TLS support is not in ORC for a long time at least I'm aware of , Could > you please confirm that ORC v1 actually compiles and run the code with > Thread locals?

Hi folks, Rather by accident than on purpose I looked at the release notes and found the following: http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#changes-to-the-jit-apis TL;DR: Orc v1 is deprecated and will be removed in the next release. I have several questions in this regard: 1. Is there a migration guide I can use to update my code to the new version? 2. Is there any development

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

Hi Bjoern, CC'ing Lang hames For questions, 1. In short yes, you can replace the memory manager, default one provided is section memory manager. 2. If you mean by " address of already compiled code", yes you can do that. Like this JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol

And yet the same C++ code using thread-local variables works fine (or seems to) when compiled with Orc v1. Does the change to the Orc API really make thread-local storage more difficult? On Fri, Dec 20, 2019 at 3:52 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Oh, I think Linux don't have support for TLS. > > On Fri, 20 Dec 2019 at 20:19, Geoff Levner

Which llvm version is more suitable to switch to orc - vs - mcjit. We don't have requirement of lazy compilation, in that case, is it worth switching? We do have requirement of ability to serialize machine code and reuse it later. MCJit seems to provide that option - how well is that supported in ORC ? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Argh. Thanks for the info. We're on Linux. On Fri, Dec 20, 2019 at 3:46 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > Gathering from past, I remember that the ORCv2 doesn't support thread > local variable but not sure what is the current status now. What platform > you are on? > CC'ed (Lang hames) he knows exactly what is the

Hi Bjoren, For question 1: As you mentioned, it is used to mangle to the symbol name and interning them, So ORC can find them at runtime in one of the JITDylibs. It would be helpful to know what you tried? (please attach code lines). For question 2: I guess you might be missing to link libraries that your program depend on, you can do that via setting up your dynamiclibrary search generator or

I don't think it's especially hard, but just not specifically unimplemented because nobody's had a strong need for it. There's probably some combinations of code models and machines that does happen to work (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support for thread locals, but as a JIT in control of the language we currently try to generate better code than

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

On Sat, 10 Aug 2019 at 21:05, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Optimize Module is just a function object. > Thank you - I fixed that now. Regards

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 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