similar to: Questions after playing around with KaleidoscopeJIT (With source files)

Hey Lang and Stefan, Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work? However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to

Hey LLVM-Mailing-List and Lang, I'm still learning how to use the ORC JIT but I finally reached the point to JIT and execute some code. For this purpose I created a test file (TestModule.cpp) and compiled it with Clang, generating two different files, one in the LLVM IR format and one in the Microsoft COFF format. The JIT resolves all undefined references, including "extern int

Hey Lang, That is really cool :D Is the creation of that table a Windows thingy or is this the way the LLVM handles it? Also… since it is COFF related – the never ending story of “finding my global constructors” first of all: Yes! I tried using the “initialize” function of LLVMJIT – however this only worked when I was loading a Module. When I added the object file (from the same source) the

Hi Björn I made a workaround for this specific issue a long time ago for the Projucer C++ JIT Engine. It basically forwards the call to another stub that provides enough space to encode a full 64-bit address. The patch is based on LLVM 3.9, so I guess it won't work out-of-the-box on a recent release, but it may give you enough hints to figure it out on your own:

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 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, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code

Hi, I still can't get IR functions to JIT compile with the ORC JIT when they contain a call to the standard math library. Attached is a minimal exploit. The program uses the KaleidoscopeJIT.h that ships with LLVM 8 (except that I had to expose the Datalayout). It reads from the filesystem an IR file (filename "func_works.ll" or "func_cos_fails.ll) and asks the ORC JIT

I'm on llvm 3.8.1 and was wondering if there's a memory leak in the removeModule impl of mcjit. In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html a module is removed from the Jit by invoking removeModule. According to the tutorial: "Its API is very simple:: addModule adds an LLVM IR module to the JIT, making its functions available for execution;

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 Lang, thank You very much. I've used Your code and the creating of the object file works. I think the problem is after creating the object file. When I link the object file with ld I get an executable, which is working right. After changing the clang and llvm libraries from the package control version (.deb) to a own compiled version with debug options, I get an assert() fault. In void

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

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.

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime error. === How to use the

I am upgrading our JIT application to use LLVM 6.0.0, and with this transition I am making the move to use the new MCJIT facility. A problem I am encountering is that the math functions from libm are not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT class which first searches the present modules and, if that is unsuccessful, continues the search in the whole process

Heyho both Mailinglists, I'm not sure if I encountered a bug or if I'm doing something wrong. I compiled a "Hello World"-function with Clang to LLVM-IR code, while passing the "-mretpoline" flag. I tried jitting and calling that function with the KaleidoscopeJIT code, but when calling "lookup" for that function the application crashed. I also tried that file

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: