search for: materializationresponsibility

...ans and how I can debug this. The assertion seems to occur just after JIT compiling a function, when my code is trying to get the compiled function's address using something like this: return ES->lookup({MainJD}, (*Mangle)(Name.str())); Here is the call stack: libravi.dll!llvm::orc::MaterializationResponsibility::notifyResolved(const llvm::DenseMap<llvm::orc::SymbolStringPtr,llvm::JITEvaluatedSymbol,llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>,llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr,llvm::JITEvaluatedSymbol>> & Symbols) Line 449 C++ libravi.dll!llvm::orc::RTDyl...

...Link(std::__1::unique_ptr<llvm::jitlink::JITLinkContext, std::__1::default_delete<llvm::jitlink::JITLinkContext> >) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLink.cpp:306 #14 0x00000001063db144 in llvm::orc::ObjectLinkingLayer::emit(llvm::orc::MaterializationResponsibility, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/ObjectLinkingLayer.cpp:343 #15 0x00000001064044f4 in llvm::orc::ObjectTransformLayer::emit(llvm::orc::MaterializationR...

...e<llvm::jitlink::JITLinkContext> >) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLink.cpp:306 >>>>> >>>>> #14 0x00000001063db144 in >>>>> llvm::orc::ObjectLinkingLayer::emit(llvm::orc::MaterializationResponsibility, >>>>> std::__1::unique_ptr<llvm::MemoryBuffer, >>>>> std::__1::default_delete<llvm::MemoryBuffer> >) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/ObjectLinkingLayer.cpp:343 >>>>> >>...

..._delete<llvm::jitlink::JITLinkContext> >) at > /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLink.cpp:306 > >>>>>>> > >>>>>>> #14 0x00000001063db144 in > llvm::orc::ObjectLinkingLayer::emit(llvm::orc::MaterializationResponsibility, > std::__1::unique_ptr<llvm::MemoryBuffer, > std::__1::default_delete<llvm::MemoryBuffer> >) at > /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/ObjectLinkingLayer.cpp:343 > >>>>>>> > >>>>>>> #15 0x000...

Hi, I am still on LLVM v6 as v7 ORC api changes were not backward compatible. Has the ORC api stabilized now with v8, or is it still under flux? Thanks and Regards Dibyendu

...ransferTo operations (see below) will apply to all associated units. You can call ResourceTracker::remove at any time to remove all symbols and resources associated with a tracker. Any active compiles associated with the tracker will receive an error when they try to update the JIT state via their MaterializationResponsibility, and will not be able to associate resources with the tracker's associated ResourceKey. You can call ResourceTracker::transferTo at any time. This will transfer tracking of all associated symbols and resources to the destination tracker. Any active compiles associated with the tracker will be...

...ed in COFF COMDAT sections [1] which allow duplicate symbol definitions to be discarded (roughly equivalent to the concept of a weak symbol). This posed two problems: (1) ORC had no idea about the (rough) mapping between COMDAT and Weak, and (2) did not support late introduction of weak symbols via MaterializationResponsibility::defineMaterializing. This caused use of the same floating point constant in multiple files to result in duplicate definition errors for the constant pool entries. Both issues have been addressed in 84217ad6611, and floating point constants should now work in COFF. If you run in to any trouble wi...

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 was loaded by another process – or not. To understand the MU...

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

...to all associated units. >> >> You can call ResourceTracker::remove at any time to remove all symbols >> and resources associated with a tracker. Any active compiles associated >> with the tracker will receive an error when they try to update the JIT >> state via their MaterializationResponsibility, and will not be able to >> associate resources with the tracker's associated ResourceKey. >> >> You can call ResourceTracker::transferTo at any time. This will transfer >> tracking of all associated symbols and resources to the destination >> tracker. Any active c...

Hi Andres, Postgres uses removable code support and Orcv1. I does make me quite > worried to see a phase where there'll be no viable way of using both in > llvm. Why isn't the right answer here to at lest develop the > replacement as a set of patches / as a branch that then can be merged as > a whole / shortly after each other, rather than just starting to develop > a

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

...yRange()? > > > > You can call ResourceTracker::remove at any time to remove all symbols > and > > resources associated with a tracker. Any active compiles associated with > > the tracker will receive an error when they try to update the JIT state > via > > their MaterializationResponsibility, and will not be able to associate > > resources with the tracker's associated ResourceKey. > > > > You can call ResourceTracker::transferTo at any time. This will transfer > > tracking of all associated symbols and resources to the destination > > tracker. Any act...