search for: resourcetrackers

Displaying 20 results from an estimated 22 matches for "resourcetrackers".

Did you mean: resourcetracker
2013 Feb 11
2
[LLVMdev] DFAPacketizer
Jonas, At this point, the DFA packetizer models a simple VLIW architecture and does not accommodate multiple stages. That's the reason for the behavior you're seeing. -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On Behalf Of *Jonas
2013 Feb 12
2
[LLVMdev] DFAPacketizer
Hi Jonas, > It is interesting to find this in the ARM backend, considering your answer. The ARM backend doesn't use the DFA packetizer. It's only used by Hexagon. At this point, there is no plan to address thisin the DFA packetizer since none of the supported targets needthe functionality. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
2013 Feb 12
0
[LLVMdev] DFAPacketizer
Hi, I looked a bit through the mail archives, and found this question answered in Oct 2011 (see below). It is interesting to find this in the ARM backend, considering your answer. Can you give more information about for example is this a temporary deficiency in the DFAPacketizer? What is the IIC_iMOVi itinerary doing below? Thanks, Jonas Thu Oct 6 15:11:25 CDT 2011: Hello Hal. > Is there
2013 Feb 18
0
[LLVMdev] DFAPacketizer
Hi Anshu, Would there be any interest in extending this algorithm to handling more extensive models, such as VLIW scheduling based on FU's and bundle space... ie handle multiple stages ? I might do it and commit, if there is acceptance and guidance... Jonas ________________________________ From: Anshuman Dasgupta [mailto:adasgupt at codeaurora.org] Sent: Tuesday, February 12, 2013 4:47 PM
2020 Apr 20
2
ORC JIT Weekly #12
Hi All, There was only one interesting ORC-specific commit this week: A new example showing how to initialize and de-initialize JITDylibs has been added in llvm/examples/OrcV2Examples/LLJITWithInitializers. The Extensible RTTI system (https://reviews.llvm.org/D39111) that I posted a while back has landed. While this is not ORC specific, I expect it to be used in upcoming patches to allow ORC
2013 Feb 11
0
[LLVMdev] DFAPacketizer
Hi, I am having problems writing the ProcessorItineraries list. As instructions on my VLIW target have varying size I want to model both cpu units and bundle bits as FUs. The following does not work, to my surprise: InstrItinData<ALU, [InstrStage<1, [BITS1,BITS2, BITS3, BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are
2020 Sep 16
2
OrcV1 removal
...-on. It should not require much code either: Both the C API and LLJIT itself are pretty thin wrappers around the core APIs -- each of these wrappers should just be a few lines. I assume it is not legal to use the same resource tracker with two > different JITDylib's? That's correct -- ResourceTrackers are bound to the JITDylib they're created from. They should assert if you use them with the wrong JITDylib, though I'm not sure how good the coverage on those asserts are yet. I think this system could be generalized to enable cross-dylib tracking at the cost of a few dozen extra bytes per...
2020 Sep 16
4
OrcV1 removal
...Merging trackers can reduce administrative overhead, especially when merging onto the default tracker for the JITDylib, which has a more compact representation for ownership of symbols. Calling JITDylib::clear() will call remove on all trackers created by the JITDylib (including the default one). ResourceTrackers have shared ownership, but the ExecutionSession and JITDylib do not retain ownership (except for the default tracker). If you release all pointers to a tracker its resources will be automatically transferred (via transferTo) to the default tracker for the JITDylib. ResourceManagers (usually Layers...
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 Oct 01
2
OrcV1 removal
Hi, On 2020-09-30 19:00:45 -0700, Lang Hames wrote: > Ok -- I'll make getting the new lookup API working a priority then. Cool. > > I see a memory leak with OrcV2 that I didn't see with V1. 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
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: /** *
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
2020 Sep 24
2
OrcV1 removal
...ly when merging onto the default tracker >> for the JITDylib, which has a more compact representation for ownership of >> symbols. >> >> Calling JITDylib::clear() will call remove on all trackers created by the >> JITDylib (including the default one). >> >> ResourceTrackers have shared ownership, but the ExecutionSession and >> JITDylib do not retain ownership (except for the default tracker). If you >> release all pointers to a tracker its resources will be automatically >> transferred (via transferTo) to the default tracker for the JITDylib. >&g...
2020 Sep 07
2
OrcV1 removal
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
2020 Jan 28
2
ORC JIT Weekly #1
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
2020 Oct 01
2
OrcV1 removal
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
2020 Sep 14
2
ORC JIT Weekly #21 -- OrcV1 removal, Removable code, and Remote TargetProcessControl
Hi All, Everything is landing all at once, just not in the mainline... yet. As discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html: OrcV1 will be removed very soon. I have posted a branch with the removal, "orcv1-removal", in my llvm fork at https://github.com/lhames/llvm-project. In addition to removing OrcV1, the orcv1-removal branch also contains a
2015 Nov 17
2
DFAPacketzer, Hexagon and bundles with 1 instruction
I'm trying to figure out how Hexagon (I'm using it as an example for my own VLIW) is handling bundles with 1 instruction, but I don't quite get it. Here is the code that I have for a endPacket // endPacket - End the current packet, bundle packet instructions and reset // DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB,
2016 Jan 20
2
a bundle with one instruction
Is there a way to place a bundle a BUNDLE instruction into a packet with one instruction? Current code to end packet doesn't handle this case: // endPacket - End the current packet, bundle packet instructions and reset // DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB, MachineInstr *MI) { if (CurrentPacketMIs.size() > 1) {
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