similar to: Kaleidoscope example error

Hi, I have been following the KaleidoscopeJIT chapters and I have found that the code might not be up to date with the current LLVM version. Is anyone aware of the supported versions of LLVM? Best, Anshil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200301/00255373/attachment.html>

Hi, I am wondering how to install the LLVM libraries for developing a compiler on Ubuntu 20.04. Kindly, Anshil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200402/b1cc2a79/attachment.html>

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

Is the ORC API currently stable enough to be recommended for use? If so, what documentation and example code represents the current recommended way of doing things with it? https://llvm.org/docs/tutorial/BuildingAJIT1.html says: "Warning: This text is currently out of date due to ORC API updates. The example code has been updated and can be used. The text will be updated once the API churn

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

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:

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

Hi Praveen, Thanks for pointing that out :) That's my mistake. I might have been misidentifying the issue with the assert statement. With those fixes made function calls seem to all call the first function called in the REPL. For example: ready> def fib(n) if (n < 2) then n else fib(n - 1) + fib(n - 2); ... ready> fib(40); Evaluated to 102334155.000000 ready> fib(10); # This

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

HI Lang, Thanks a bunch for the reply. That worked great for on my end and is a pretty tiny change. Really appreciate all the work you've done on this new JIT stuff and putting together those great tutorials. Zeke On Thu, Aug 8, 2019 at 3:07 PM Lang Hames <lhames at gmail.com> wrote: > > Hi Zeke, > > Thanks for pointing this out. > > You're right: the issue is

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is

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

To try to find out why it was crashing, I followed the trail of function calls: C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp auto ExprSymbol = J.findUnmangledSymbol("__anon_expr"); JITSymbol findUnmangledSymbol(const std::string Name) { return findSymbol(mangle(Name)); } JITSymbol findSymbol(const std::string &Name) { return CompileLayer.findSymbol(Name,

HI Dibyendu, A single MCJIT instance can notionally manage multiple modules, but there are caveats (which I'm afraid I don't remember off the top of my head) that make it unattractive in practice. I believe most clients opt for something like the ExecutionEngine-per-Module model used in the Kaleidoscope tutorials. As Dave mentioned, I'm also working on some new JIT APIs (Orc) that

Hi, I am building a new JIT compiler for Lua (actually a derivative of Lua), and am planning to use LLVM for this. I have trying out some basic functions using LLVM 3.5.1. I have been puzzled by one aspect of the MCJIT versions of the Kaleidoscope sample, and would hugely appreciate some insight. Can a single MCJIT instance be used to manage several modules? Why is a separate MCJIT instance

Hello LLVM developers, I am developing a small project using LLVM. The objective is to provide dynamic loading via JIT compilation of C++ code contained in a (TS) module. For this reason, I would like to return an explicitly raw void pointer (resembling libdl's `void *dlsym(void *, char const *);` as closely as possible) to the compiled result. The MCJIT class offers the most convenient API

Hello there, I finished Chapter 1 of the Kaleidoscope tutorial for using the Orc JIT API. I played around with some things and ended with some questions. 1. What is the use of "MangleAndInterner"? I read it is used to mangle the name for the lookup search, but I seem to be not able to use it correctly. In my first attempt I used the mangled name of my function

On Tue, Apr 21, 2015 at 7:26 AM, Per Mildner <Per.Mildner at sics.se> wrote: > Charlie Turner <charlesturner7c5 <at> gmail.com> writes: > > > I was planning on committing these changes with the corresponding > > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a > > surprise to have no explanation of what MCJITHelper and friends is

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