search for: resourcetrack

...ge<1, [BITS1,BITS2, BITS3, BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions per cycle. ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); DFAPacketizer.cpp:84: void llvm::DFAPacketizer::reserveResources(const llvm::MCInstrDesc*): Assertion `Cach...

...0>, > > InstrStage<1, [ALU1, ALU2]>]> > > I want to express that there are two ALU's, and four bundle slots, and > in this case while allocating this type of instructions several times, > I would like to be allowed only two such instructions per cycle. > > ResourceTracker->reserveResources(); > > ResourceTracker->reserveResources(); > > ResourceTracker->reserveResources(); > > ResourceTracker->reserveResources(); > > ResourceTracker->reserveResources(); > > DFAPacketizer.cpp:84: void llvm::DFAPacketizer::reserveResource...

..., BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions per cycle. ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); DFAPacketizer.cpp:84: void llvm::DFAPacketizer::reserveResources(const llvm::MCInstrDesc*): Assertion `CachedTabl...

..., BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions per cycle. ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); DFAPacketizer.cpp:84: void llvm::DFAPacketizer::reserveResources(const llvm::MCInstrDesc*): Assertion `CachedTabl...

...y type, e.g. prioritizing stubs and other trivial-to-materialize symbols. Finally, I hope to spend next week working on support for removable code in OrcV2, which is one of the big missing features from OrcV1. I expect the API to end up looking something like this: using ResourceKey = const class ResourceTracker*; class ResourceTracker { public: // Return the key for this tracker (just its address) ResourceKey getKey() { return this; } // Emit all not-yet-emitted symbols covered by this tracker. Expected<SymbolMap> emit(); // Remove all symbols covered by this tracker and // release r...

..., BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions per cycle. ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); ResourceTracker->reserveResources(); DFAPacketizer.cpp:84: void llvm::DFAPacketizer::reserveResources(const llvm::MCInstrDesc*): Assertion `CachedTabl...

...lly do the same for resource trackers, if I understand this > correctly. Sketching out what I'd need to do to test postgres, so I > don't waste time going in the wrong direction: 1) Add API for management (create, destroy) a non-default resource tracker > (i.e. JITDylib::createResourceTracker) > 3) Add JITDylib::clear() wrapper > 2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument > (defaulting to NULL for the default resource tracker?) to specify the > resource tracker > 4) LLJIT would need to grow the underlying support methods That's all...

...val) 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 Core.h: *ResourceTracker* -- Your handle to remove code from a JITDylib. Also allows tracking to be merged onto another tracker (reducing the administrative overhead required for tracking). *ResourceKey* -- An opaque key associated with each tracker. *ResourceManager* -- A listener interface to be notified when resources...

...sicIRLayerMaterializationUnit, llvm::orc::IRLayer&, llvm::orc::IRSymbolMapper::ManglingOptions const&, llvm::orc::ThreadSafeModule>(llvm::orc::IRLayer&, llvm::o> | | | ->03.53% (97,542B) 0x83B1C7D: llvm::orc::IRLayer::add(llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>, llvm::orc::ThreadSafeModule) (Layer.cpp:28) | | | ->03.53% (97,542B) 0x83BCBF5: llvm::orc::LLJIT::addIRModule(llvm::orc::JITDylib&, llvm::orc::ThreadSafeModule, llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>) (LLJIT.cpp:990) | | |...

...I'm not yet > > sure where exactly they're coming from. Possible that I'm just missing a > > step somewhere. Or something around the removable code support doesn't > > yet fully work. > > I just checked and I've migrated ObjectLinkingLayer to support > ResourceTracker, but not RTDyldObjectLinkingLayer yet. If you're testing on > Linux there's a good chance that's the source of your leak. I'll get that > updated tonight. I indeed am testing on linux... Thanks. Regards, Andres

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: /** * Create a ThreadSafeModule wrapper around the give...

...gt; llvm::orc::IRLayer&, llvm::orc::IRSymbolMapper::ManglingOptions const&, >> llvm::orc::ThreadSafeModule>(llvm::orc::IRLayer&, llvm::o> >> | | | ->03.53% (97,542B) 0x83B1C7D: >> llvm::orc::IRLayer::add(llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>, >> llvm::orc::ThreadSafeModule) (Layer.cpp:28) >> | | | ->03.53% (97,542B) 0x83BCBF5: >> llvm::orc::LLJIT::addIRModule(llvm::orc::JITDylib&, >> llvm::orc::ThreadSafeModule, >> llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>)...

...week unfortunately. I'm still landing unit > tests and cleanups on the OrcV1 removal branch, but I hope to put out an > ORC Weekly update on Friday covering the latest developments. In the > meantime you can find some very basic example usage in > llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp ( > https://github.com/lhames/llvm-project/blob/orcv1-removal/llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp > ). > > -- Lang. > > On Wed, Sep 16, 2020 at 11:52 AM Lang Hames <lhames at gmail.com> wrote: > >> Hi All, >> >> I've...

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

Hi Andres, I also want to highlight the necessity of some form of C API, that others > already have. > <snip> > It's fine if the set of "somewhat stable" C APIs doesn't provide all the > possible features, though. Ok. This got me thinking about what a simple LLJIT API should look like. I have posted a sketch of a possible API on http://llvm.org/PR31103 . I

Hi, On 2020-09-30 17:52:46 -0700, Lang Hames wrote: > I've just realised that we're going to need a change to the definition > generator API in the long term: Right now it is called under the session > lock, but we want to shift to calling it outside the lock and passing a > lookup-continuation. This would allow definition discovery to take an > arbitrarily long time

...project. In addition to removing OrcV1, the orcv1-removal branch also contains a prototype of the removable code feature. I'm going to discuss this at greater length over the next couple of weeks, but if anyone's interested in playing with the prototype I'd recommend starting with the *ResourceTracker* class in https://github.com/lhames/llvm-project/commit/de6f6d57d3e955b998f82ab6e610da41fcb09492 . Finally, adding removable code unblocked another prototype I've been working on: an OrcRPC based TargetProcessControl implementation. I've added that to the "orcv1-removal-with-remote-...

.../ DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB, MachineInstr *MI) { if (CurrentPacketMIs.size() > 1) { MachineInstr *MIFirst = CurrentPacketMIs.front(); finalizeBundle(*MBB, MIFirst, MI); } CurrentPacketMIs.clear(); ResourceTracker->clearResources(); } Based on this, it looks like packets with one instruction are not finalized (finalizeBundle is the one which inserts a BUNDLE instruction). So what happens with packets that have only 1 instruction? Is there a separate pass that creates a bundle from a single instruction?...

.../ DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB, MachineInstr *MI) { if (CurrentPacketMIs.size() > 1) { MachineInstr *MIFirst = CurrentPacketMIs.front(); finalizeBundle(*MBB, MIFirst, MI); } CurrentPacketMIs.clear(); ResourceTracker->clearResources(); } My initial idea was to simply add a NOP instruction to the CurrentPacketMIs, but it is proving to be more difficult than I thought. Would anyone care to help? -- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attac...

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