similar to: RFC: Should SmallVectors be smaller?

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

In SmallVector.h: class SmallVectorBase { *protected:* void *BeginX, *EndX, *CapacityX; *protected:* SmallVectorBase(void *FirstEl, size_t Size) : BeginX(FirstEl), EndX(FirstEl), CapacityX((char*)FirstEl+Size) {} In StringMap.h: class StringMapImpl { *protected:* // Array of NumBuckets pointers to entries, null pointers are holes. // TheTable[NumBuckets] contains a sentinel value

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

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; }

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); >

Is anybody using the LLVM/clang/lldb compiled with the MSVC 2019 (x86-32bit) successfully? I am getting crash in SmallVector at multiple places after a llvm:SmallVector is being moved around in move constructor or move operator=. Not sure what is going on. ~SmallVectorImpl() { if (!this->isSmall()) free(this->begin()); // <=== crash here, line 336 SmallVector.h } The

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

> On Jun 23, 2018, at 10:14, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Jun 23, 2018, at 9:11 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote: >> >>> >>> I think we might be better off just reducing the pre-allocation size of most of our SmallVectors across LLVM and Clang.

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 >

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; }

In r271357 I've committed GDB pretty printer script for the following types - ArrayRef $1 = llvm::ArrayRef of length 3 = {1, 0, 7} - StringRef $2 = "foo\000bar" $3 = "fo" - SmallString $4 = "foo\000bar" - *SmallVector(Impl)* $5 = llvm::SmallVector of length 3, capacity 3 = {1, 0, 7} All of these visualizers are pretty simple, robust,

+update diff 2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > I outlined (is that the right > word?) raw_char_ostream::grow, raw_char_ostream::write (both) into > raw_ostream.cpp with less than 10% difference in performance. > > Profiling reveals that the real culprit is the code line > > OS.reserve(OS.size() + 64); > > called from

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

+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

I get a segfault with this code when setting the data layout: int main(int argc, char** argv) { llvm::InitializeNativeTarget(); llvm::LLVMContext TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName());

Hi all, Thought I should say something - it''s been a little while. :) Anyway, I''m still futzing with how I want the Ruby API to look. The more I look at the Perl version, the more I think it was too faithful to the C API. Right now I''m looking at the trigger() method. For example, I don''t see any reason to make the "type" key take a hash as an

My code to create an ExecutionEngine is segfaulting: std::string errStr; llvm::ExecutionEngine * ee = llvm::EngineBuilder( unique_ptr<llvm::Module>(module) ) .setErrorStr( &errStr ) //line 1618 .setEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during

Ok. I can make a copy of the unique_ptr before moving it into the builder's constructor and use the copy later on. It is confusing to require a unique_ptr. Frank On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote: > I am constructing the engine builder in the following way: > > llvm::SMDiagnostic Err; > unique_ptr<Module> Mod = getLazyIRFileModule("f.ll",

Dear list, I recently tried to add instrumentation to SmallVector for using Address sanitizer to detect cases where references used after they are invalidated. This basic implementation for this is here - https://reviews.llvm.org/D87237 However, in adding/testing this, I did uncover some questionable code. Firstly `SmallString<unsigned>::c_str()` and