search for: capacityx

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

...orward 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 *BeginX, *EndX, *CapacityX; T Small[SmallCapacity]; bool isSmall() const { return BeginX == Small; } T *begin() { return BeginX; } T *end() { return EndX; } size_t size() const { return EndX - BeginX; } size_t capacity() const { return CapacityX - BeginX; } }; ``` In the past I used something more like: ``` tem...

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; } ~/llvm-project/llvm/include/llvm/ADT/SmallVector.h:327 (svn rev: 107560) This function was wrote/last modified by lattner. Why a goto? For CPU bra...

...ul 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); > this->setEnd(this->end()+1); > return; > } > this->grow(); > goto Retry; > } > > ~/llvm-project/llvm/include/llvm/ADT/SmallVector.h:327 (svn rev: 107560) > This function was w...

...ery 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 two sets of pointers need to be coordinated between the SmallString and raw_svector_ostream using raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync and raw_svector_ostream::write_i...

...e data structure. If no one has measured before I might try it some time. > -Chris > > >> >> The current scheme works out to something like this: >> ``` >> template <class T, size_t SmallCapacity> >> struct SmallVector { >> T *BeginX, *EndX, *CapacityX; >> T Small[SmallCapacity]; >> >> bool isSmall() const { return BeginX == Small; } >> T *begin() { return BeginX; } >> T *end() { return EndX; } >> size_t size() const { return EndX - BeginX; } >> size_t capacity() const { return CapacityX - BeginX; } >...

...; 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 two sets of pointers need to be coordinated >> between the SmallString and raw_svector_ostream using >> raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostr...

...t; ... >>>> 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 two sets of pointers need to be coordinated >>>> between the SmallString and raw_svector_ostream using >>>> raw_svector_ostream::init, raw_s...

...;>> >> >>>> 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 two sets of pointers need to be coordinated >> >>>> between the SmallString and raw_svector_ostream using >> >...

...>>>>>> >>>> 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 two sets of pointers need to be > >>>>>> >>>...

...ector_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 two sets of pointers need to be >>>>> coordinated >>>>> >>>&gt...

...t; >>>> 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 two sets of pointers need to be coordinated >>> >>>> between the SmallString and raw_svector_ostream usi...

...t;>>> 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 two sets of pointers need to be > >> &...