search for: stringmapentry

...use the assertion not explicitly occurs in my code, it occurs in the library code which I'm using in my threads. Assertion I'm getting is this: Global Value is CRO: /home/preejackie/spicy/orcs/llvm/include/llvm/ADT/DenseMap.h:1242: bool llvm::DenseMapIterator<const llvm::Value *, llvm::StringMapEntry<llvm::Value *> *, llvm::DenseMapInfo<const llvm::Value *>, llvm::detail::DenseMapPair<const llvm::Value *, llvm::StringMapEntry<llvm::Value *> *>, false>::operator!=(const llvm::DenseMapIterator::ConstIterator &) const [KeyT = const llvm::Value *, ValueT = llvm::Strin...

...931 101,141 0 ... ->16.97% (469,433B) 0xB29E471: llvm::allocate_buffer(unsigned long, unsigned long) (MemAlloc.cpp:15) | ->03.54% (97,812B) 0x831FB40: llvm::MallocAllocator::Allocate(unsigned long, unsigned long) (AllocatorBase.h:85) | | ->03.54% (97,812B) 0x8330268: llvm::StringMapEntry<std::atomic<unsigned long> >* llvm::StringMapEntry<std::atomic<unsigned long> >::Create<llvm::MallocAllocator, int>(llvm::StringRef, llvm::MallocAllocator&, int&&) (StringMapEntry.h:101) | | ->03.54% (97,812B) 0x8322B26: std::pair<llvm::StringMapIte...

...% (469,433B) 0xB29E471: llvm::allocate_buffer(unsigned long, >> unsigned long) (MemAlloc.cpp:15) >> | ->03.54% (97,812B) 0x831FB40: llvm::MallocAllocator::Allocate(unsigned >> long, unsigned long) (AllocatorBase.h:85) >> | | ->03.54% (97,812B) 0x8330268: >> llvm::StringMapEntry<std::atomic<unsigned long> >* >> llvm::StringMapEntry<std::atomic<unsigned long> >> >::Create<llvm::MallocAllocator, int>(llvm::StringRef, >> llvm::MallocAllocator&, int&&) (StringMapEntry.h:101) >> | | ->03.54% (97,812B) 0x8322...

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: /** *

...e data in each SmallDenseMap and sort it by the hash as a key - it's unique after all, and doing each map separately won't do crazy bad things to memory usage (a small constant overhead). Handling the StringMap, I'm not sure about - it might be cheap enough to make a separate vector of StringMapEntry*s, sorting based on the strings and iterating over that instead of the StringMap itself? (I guess the same approach could be taken with the SmallDenseMaps, rather than duplicating anything) How's all that sound? -------------- next part -------------- An HTML attachment was scrubbed... URL: &l...

...rapni/local/include/llvm/PassManager.h:20, from /waflhome/trapni/local/include/llvm/Support/StandardPasses.h:22, from /waflhome/trapni/local/src/flow/src/Runner.cpp:19: /waflhome/trapni/local/include/llvm/ADT/StringMap.h: In static member function 'static llvm::StringMapEntry<ValueTy>* llvm::StringMapEntry<ValueTy>::Create(const char*, const char*, AllocatorTy&, InitType)': /waflhome/trapni/local/include/llvm/ADT/StringMap.h:170:33: error: expected primary-expression before '<' token /waflhome/trapni/local/include/llvm/ADT/StringMap.h:170:...

...the hash as a key - it's unique after all, and >> doing each map separately won't do crazy bad things to memory usage (a >> small constant overhead). >> >> Handling the StringMap, I'm not sure about - it might be cheap enough to >> make a separate vector of StringMapEntry*s, sorting based on the strings >> and iterating over that instead of the StringMap itself? (I guess the same >> approach could be taken with the SmallDenseMaps, rather than duplicating >> anything) >> >> How's all that sound? >> > > See above -- I don&...

...it's unique after all, and >>> doing each map separately won't do crazy bad things to memory usage (a >>> small constant overhead). >>> >>> Handling the StringMap, I'm not sure about - it might be cheap enough to >>> make a separate vector of StringMapEntry*s, sorting based on the strings >>> and iterating over that instead of the StringMap itself? (I guess the same >>> approach could be taken with the SmallDenseMaps, rather than duplicating >>> anything) >>> >>> How's all that sound? >>> >&...

...a symbol is in a COMDAT group. f) Those clients will also generally care about efficiently iterating over all the symbols in that group. I'd suggest having a bit on GlobalValue and a side-table on the Module mapping from GVs to COMDAT objects, where COMDAT objects are allocated as part of the StringMapEntry on the Module and don't really contain any data except their name and a list of GV*s, heavily optimized for the two-element case. John.

> Unfortunately, making the comdat be for the entire function is not > conformant with the ABI, which says that you either put the variable > and its guard in different comdats or you put them in a single comdat > named for the variable.  It also doesn't actually help unless we disable > inlining. I see. Using two comdats would still cause the same problem for us, no? So the

On Nov 9, 2011, at 11:34 AM, Rafael Espíndola wrote: >>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals >>> (even in TUs where static initialization is required to be performed), unless >>> we can prove that every translation unit will use static initialization. We >>> emit the global plus its guard variable as a single object so

Hi List, My IR compiles fine and runs. I've tried to add DebugIR pass so as to be able to debug and profile it (since source is an SQL query all that I can debug and profile is IR itself). When I tried to add it to pass manager I got the following assert: Program received signal SIGABRT, Aborted. 0x00007ffff3fe4425 in __GI_raise (sig=<optimized out>) at

...& "Expected non-null context"); > ... > + static MDStringRef get(LLVMContext &Context, StringRef String); > > You have reference/pointer disagreement, I’d recommend taking LLVMContext& to the ctor for uniformity (and remove the assert). This is a workaround for `StringMapEntry`'s imperfect forwarding -- it passes the `InitVal` constructor argument by value. I'll fix the problem at its source and clean this up. > +class ReplaceableMetadataImpl { > > I’m not following your algorithm intentions well yet, but this seems like a really heavy-weight implemen...

TL;DR: If you use metadata (especially if it's out-of-tree), check the numbered list of lost functionality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for