similar to: ORC JIT - different behaviour of ExecutionSession.lookup?

Hey Lang, Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication. My big problem is still handling cross references between modules with “our” name scheme. Since our old

Hey Lang, > Do you mean that the object file is produced by another process and is being loaded into your JIT process for execution, or that you want your JIT to produce code for several different processes? These are different problems with different solutions. I'll wait until I understand your use case to answer further. In the current state we don’t have a JIT only an handcrafted object

Hey Lang, Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O< With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file

Hey Lang, I would be really happy to only have one LLJIT instance and using multiple JITDylibs. However… it seems like that I don’t know enough to use them. So I wonder… 1. When I add Module A to JITDylib A and Module B to JITDylib B – where will those look for undefined symbols? Will Module A for example: will it only search itself and the MainDylib? Or would it also search in JITDylib B?

Hi Lang, Thank you for your answer! This helped me again a lot!! Also that ResourceTracker is a really neat feature! Looking forward to it! :3 I changed the title cause… there is another issue I have (sorry about that…) I’m finally allowed to investigate the ORC JIT for integration into our system, which meant I got a few days to actually play around with it. However, another problem arise

Hi Bjoern, Thanks for your patience. The good news is that there is a neater way to do this: ExecutionSession's lookup methods take a orc::SymbolState parameter which describes the state that symbols must reach before a query can return (See https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In your case you

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Hello, I am trying to run this basic C++ hello-world code in my iOS app that has LLVM libraries linked in (the app runs on the actual device - iPad Pro, iOS 13.4.1). #include <iostream> int main (int argh, char *argv[]) { std::cout << "Hello World!" << std::endl; return 0; } So below is the break down of the steps that I do: First I compile this code to an

Hi Lang, Please see below is the trace. -- Thanks, Igor *2020-06-06 12:05:21.016705-0400 CppDevProCompiler[6613:3000073] Running...* *jitLink_MachO: magic = 0xfeedfacf, identifier = "llvm-link.submodule-jitted-objectbuffer"* *jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000* *Creating normalized sections...* * __text: 0x0000000000000000 -- 0x0000000000000064, align:

Hi Dave, Yep. This is JITLink specific, so we could only have observed it on MachO x86-64 or arm64 until recently. It takes a little bit of poking to get IR to produce a zero-lengh section on MachO, but not much. Jared Wyles recently contributed an initial JITLink ELF implementation, so the fix seems timely -- we might have been about to see more of it. -- Lang. On Fri, Jun 19, 2020 at 4:02 PM

Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at

Hello, After commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f we have new warning but only if compiled with GCC: In file included from /path/to/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h:19:0, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:23, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9:

Hi, I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely tracking tip-of-tree), so linking new object files and patching in the new function(s) will happen frequently. One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2)

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

Hi, On 2020-10-01 15:29:12 -0700, Lang Hames wrote: > 24bytes / object -- Looks like I managed module ownership correctly but > leaked the ThreadSafeModule container. This should be fixed in 5044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we

Generally it is preferable to store bitfields using plain integer types because MSVC has surprising behavior when packing bitfields of differing type. MSVC, for example, will not back this into one byte: bool a : 1; uint8_t b : 2; bool c : 1; So, for LLVM or any other cross platform project, I recommend storing enums as some integer type, using the same type for all bitfields, and adding

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

Hi All, I've updated the orcv1 removal branch ( https://github.com/lhames/llvm-project/tree/orcv1-removal) with an initial patch for removable code. If anyone wants to follow along with the development or share thoughts on the design you're very welcome to. I'll be adding tests and comments this week, but for anyone who wants to take an early look the main elements are defined in

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

I tried checking out the latest llvm/clang from SVN (as of a few hours ago) and compiling it (clang 3.6.1 doesn't compile 3.7 because it fails a version check, so I repeated the technique of compiling with Microsoft C++ first, then using the resulting clang-cl.exe). It fails with a bunch of error messages along the lines of: LLVMSupport.lib(Atomic.obj) : error LNK2019: unresolved external