search for: beginx

...uld 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 *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...

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[NumBucke...

...eason to fork the 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 Capacit...

...#39;'t see any reason to make the "type" key take a hash as an argument (thus creating a nested hash) when none of the keys are duplicate. We should just DTRT (do the right thing). Also, I mostly dislike camel case and I''m not sure what logic MS used when it chose "BeginX" versus "StartX". I''m just going to use "start". So for now I''m looking at something like this: t = Trigger.new(task_name,some_host) t.trigger = { :start_year => 2004 :start_month => 4 :start_day => 25 :start_hour => 23 :sta...

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

...nstances to drop the size argument. Note that a SmallVector with N value of 0 takes the same storage as an N value of 1, so very large sizeof(T) would still use more than 6 pointers. The cause is that SmallVectorTemplateCommon stores the first element so that it can detect small mode by comparing BeginX against &FirstEl. The fix would be to shave a bit off of capacity (dropping max capacity to 2B)... likely reasonable. If we're going to audit anyway, I wonder if forking names would make sense. E.g., the current thing would be less tempting to use in data structures if it were called Sta...

...\"\"\"Print an llvm::SmallString object.\"\"\"\n" .ascii "\n" .ascii " def __init__(self, val):\n" .ascii " self.val = val\n" .ascii "\n" .ascii " def to_string(self):\n" .ascii " begin = self.val['BeginX']\n" .ascii " end = self.val['EndX']\n" .ascii " return begin.cast(gdb.lookup_type(\"char\").pointer()).string(length = end - begin)\n" .ascii "\n" .ascii " def display_hint (self):\n" .ascii " return 'string'...

...8> 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::pwrit...

...t;> 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_o...

...he size argument. >> >> Note that a SmallVector with N value of 0 takes the same storage as an N value of 1, so very large sizeof(T) would still use more than 6 pointers. The cause is that SmallVectorTemplateCommon stores the first element so that it can detect small mode by comparing BeginX against &FirstEl. The fix would be to shave a bit off of capacity (dropping max capacity to 2B)... likely reasonable. > > The patch LGTM, but why would someone actually have a SmallVector with N = 0? Isn’t that a vector? It's a vector that can be passed as a SmallVectorImpl parame...

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

...ext 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 > >>>>&g...

...gt; 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 >>>>&...

...;> >>> >>>> 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_...

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