search for: orcs

Displaying 20 results from an estimated 487 matches for "orcs".

Did you mean: orc
2020 May 23
4
Assertion triggered when running simple hello-world code on iOS device using ORC/LLLazyJIT
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
2020 Jun 06
4
Assertion triggered when running simple hello-world code on iOS device using ORC/LLLazyJIT
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:
2020 Oct 01
2
OrcV1 removal
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
2020 Apr 16
4
ORC Assertion failure
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 ==
2020 Jun 20
1
Assertion triggered when running simple hello-world code on iOS device using ORC/LLLazyJIT
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
2020 Oct 02
2
OrcV1 removal
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 names we generate >> are unique over time. But the interned strings aren't cleared ever. I...
2020 Oct 01
2
OrcV1 removal
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:
2012 Apr 08
1
DLLs for Orcs Must Die
Hi, I could install Orcs Must Die, but when I try to run it, I get the following errors: Code: err:module:import_dll Library fmod_event.dll (which is needed by L"C:\\Programme (x86)\\Robot Entertainment\\Orcs Must Die!\\Build\\release\\OrcsMustDie.exe") not found err:module:import_dll Library lua90.dll (which i...
2019 Aug 13
2
VModuleKey K not valid here
Hi, I am getting following assertion failure when attempting to remove a module. /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT =
2016 May 17
3
External function resolution: MCJIT vs ORC JIT
When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function
2019 Sep 19
3
"corrupted size vs. prev_size" when calling ExecutionSession::lookup()
Hi, I wrote a compiler that generate IR code and run it on the JIT, and there randomly crashed due to "corrupted size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit
2018 Sep 11
2
JIT tests on AArch64
Hi all, I am seeing a number of JIT unit test failures on AArch64. Some googling returns past discussions (circa 2014) but as far as I can tell, everything should be working. I listed the failures below. These are from a Release build. A Debug build does not exhibit the failures. I built with gcc 6.1.0 on SuSE 12. Switching to gcc 8.2.0 also makes the problem go away, both in Debug and
2016 Mar 29
0
MCJIT versus Orc
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
2012 Aug 29
4
xen debugger (kdb/xdb/hdb) patch for c/s 25467
Hi Guys, Thanks for the interest in the xen hypervisor debugger, prev known as kdb. Btw. I''m gonna rename it to xdb for xen-debugger or hdb for hypervisor debugger. KDB is confusing people with linux kdb debugger and I often get emails where people think they need to apply linux kdb patch also... Anyways, attaching patch that is cleaned up of my debug code that I accidentally left in
2020 Sep 23
2
ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup
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
2017 Aug 24
1
Invalid Signature of orc::RTDyldObjectLinkingLayer::NotifyLoadedFtor
Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"
2018 Nov 05
2
ORC JIT api, object files and stackmaps
I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save
2016 Mar 29
1
MCJIT versus Orc
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
2016 May 19
2
External function resolution: MCJIT vs ORC JIT
Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow. Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows? -- lg > On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Larry, > > You're basically there, but you're hitting
2016 May 22
1
External function resolution: MCJIT vs ORC JIT
>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) This is one is a bit tricky and hard to find. I spent quiet some time digging into MC and ORC JIT execution engines trying to find what makes them work. The problem is that this trick (LoadLibraryPermanently) happens inside of EngineBuilder, despite that the functionality belongs to a JIT engine itself, not to the builder. I