similar to: Why duplicate "protected:" in SmallVector.h, StringMap.h?

Hello everyone! I'm a newcomer for the great LLVM project. I've started to explore the source code of LLVM project to become more familiar with it, and I've found some strange usage of move semantics in constructor of StringMapImpl( StringMapImpl &&RHS) {...} class in include/llvm/ADT/StringMap.h line 56. Could anyone explain me the purpose of zeroing of all fields of RHS in

This series of patches address several issues causing memory usage to grow indefinetely on a long lived process. These are not convenional leaks -- memory would have been freed when the LLVM context or/and JIT engine is destroyed -- but for as long as they aren't the memory is usage effectively ubounded. The issues were found using valgrind with '--show-reachable=yes' option: 1.

I've been curious for a while whether SmallVectors have the right speed/memory tradeoff. It would be straightforward to shave off a couple of pointers (1 pointer/4B on 32-bit; 2 pointers/16B on 64-bit) if users could afford to test for small-mode vs. large-mode. The current scheme works out to something like this: ``` template <class T, size_t SmallCapacity> struct SmallVector { T

Thanks, I tried calling ResetAllOptionOccurrences after the run like this… // Compile the module TimeCompilations times to give better compile time // metrics. for (unsigned I = TimeCompilations; I; --I) if (int RetVal = compileModule(argv, Context)) return RetVal; if (YamlFile) YamlFile->keep(); cl::ResetAllOptionOccurrences(); return 0; } Unfortunately

A very common code pattern in LLVM is SmallString<128> S; raw_svector_ostream OS(S); OS<< ... Use OS.str() While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer: In SmallString: void *BeginX, *EndX, *CapacityX In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur Moreover, at runtime the

>> On Jun 21, 2018, at 18:38, Chris Lattner <clattner at nondot.org> wrote: >> >> >> >> On Jun 21, 2018, at 9:52 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I've been curious for a while whether SmallVectors have the right speed/memory tradeoff. It would be straightforward to shave off a couple of

> On Jun 22, 2018, at 15:18, Reid Kleckner <rnk at google.com> wrote: > > On Thu, Jun 21, 2018 at 9:16 PM Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Out of curiosity, what brings this up? > > I've noticed that Clang is using more stack recently (we're seeing more crashes from

Sean, thanks for reminding this, Alp did commit a class derived from raw_svector_ostream conatining an internal SmallString he called small_string_ostream. The commit was reverted after a day due to a disagreement about the commit approval and apparently abandoned. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223393.html

Hello, I have just a little question about the SmallVector implemention. In SmallVectorImpl, the following method is currently implemented as: void push_back(const T &Elt) { if (this->EndX < this->CapacityX) { Retry: new (this->end()) T(Elt); this->setEnd(this->end()+1); return; } this->grow(); goto Retry; }

I don't think we should make flush virtual. Why do you need to do it? Can't you set up the base class to write to use the tail of the memory region as the buffer? On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > Is this what you're thinking about? > The code is not tested yet, I'd like to know if the overall direction and >

On Jul 4, 2010, at 12:04 AM, bombela wrote: > Hello, > > I have just a little question about the SmallVector implemention. > > In SmallVectorImpl, the following method is currently implemented as: > > void push_back(const T &Elt) { > if (this->EndX < this->CapacityX) { > Retry: > new (this->end()) T(Elt); >

From: José Fonseca <jfonseca at vmware.com> When the hash function uses object pointers all free entries eventually become tombstones as they are used at least once, regardless of the size. DenseMap cannot function with zero empty keys, so it double size to get get ridof the tombstones. However DenseMap never shrinks automatically unless it is cleared, so the net result is that certain

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; }

Hi: I'm building a small tool on top of LLVM Core Library. ``` LLVMContext context; SMDiagnostic diag; Module *M = parseIRFile(InputIR, diag, context).get(); if (M == nullptr) { diag.print("LLVM", errs()); exit(-1); } assert(M->isMaterialized() && "Module not materialized!"); PointerType *ArrayPtrTy =

+llvm-dev at lists.llvm.org The impact should be small as all the other streamers usually write directly to the memory buffer and only when out of buffer they call write(). OTOH, raw_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for

On OS X, this test: ------------------------------------------------------ #include <llvm/ADT/DenseSet.h> #include <new> #include <stdio.h> int main(int argc, char** argv) { llvm::DenseSet<unsigned> set(2); set.insert(0); set.insert(1); if (set.count(2)) printf("error\n"); return 0; } ------------------------------------------------------ saved

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the

Hi! I used to have arch linux running on 1 btrfs partition (sda1, incl. /boot). When switching to 3.2.5 recently the system fails to boot: (after udevd) /etc/rc.sysinit: line 15: 117 Bus error mountpoint -q /proc and so on, no idea. It used to boot with 3.2.4, but 1) I obviously had some corruption in the tree, when I tried to delete a certain file I hit e.g. "kernel BUG at

Currently the fs sync function (super.c:btrfs_sync_fs()) doesn''t wait for delayed work to finish before returning success to the caller. This change fixes this, ensuring that there''s no data loss if a power failure happens right after fs sync returns success to the caller and before the next commit happens. Steps to reproduce the data loss issue: $ mkfs.btrfs -f /dev/sdb3 $

[11558.527680] ------------[ cut here ]------------ [11558.527708] kernel BUG at fs/btrfs/transaction.c:1337! [11558.527730] invalid opcode: 0000 [#1] PREEMPT SMP [11558.527764] CPU 1 [11558.527776] Modules linked in: loop nls_cp437 vfat fat dm_mod xfs exportfs jfs usb_storage uas fuse ext4 jbd2 mbcache snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwlwifi snd_hda_intel snd_hda_codec uvcvideo