search for: smallvectors

...not having to read/write "N", or do an extra edit/recompile cycle if you forgot it 2. avoiding pathological cases: The choice of N is usually semi-arbitrary in our experience, and if one isn't careful, can result in sizeof(SmallVector) becoming huge, especially in the case of nested SmallVectors. This patch avoids pathological cases in two ways: A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which prevents pathological size amplifications like in `SmallVector<struct {SmallVector<T, 4> a, b; }, 4>`, where the small sizes effectively multiply together. Of...

..., or do an extra > edit/recompile cycle if you forgot it > > > > 2. avoiding pathological cases: The choice of N is usually > semi-arbitrary in our experience, and if one isn't careful, can result in > sizeof(SmallVector) becoming huge, especially in the case of nested > SmallVectors. This patch avoids pathological cases in two ways: > > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which prevents > pathological size amplifications like in `SmallVector<struct > {SmallVector<T, 4> a, b; }, 4>`, where the small sizes effectively m...

On Tue, Nov 17, 2020 at 7:26 AM Chris Lattner <clattner at nondot.org> wrote: > On Nov 13, 2020, at 2:06 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > We've pretty happy now with a patch that adds two wrappers around > SmallVector that make it 1) more convenient to use and 2) will tend to > mitigate misuse of SmallVector. We think

...gt; edit/recompile cycle if you forgot it > >> > > >> > 2. avoiding pathological cases: The choice of N is usually > semi-arbitrary in our experience, and if one isn't careful, can result in > sizeof(SmallVector) becoming huge, especially in the case of nested > SmallVectors. This patch avoids pathological cases in two ways: > >> > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which > prevents pathological size amplifications like in `SmallVector<struct > {SmallVector<T, 4> a, b; }, 4>`, where the small sizes effe...

...quot;N", or do an extra edit/recompile cycle if you forgot it >> > >> > 2. avoiding pathological cases: The choice of N is usually semi-arbitrary in our experience, and if one isn't careful, can result in sizeof(SmallVector) becoming huge, especially in the case of nested SmallVectors. This patch avoids pathological cases in two ways: >> > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which prevents pathological size amplifications like in `SmallVector<struct {SmallVector<T, 4> a, b; }, 4>`, where the small sizes effectively multipl...

...cycle if you forgot it > >> >> > > >> >> > 2. avoiding pathological cases: The choice of N is usually > semi-arbitrary in our experience, and if one isn't careful, can result in > sizeof(SmallVector) becoming huge, especially in the case of nested > SmallVectors. This patch avoids pathological cases in two ways: > >> >> > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which > prevents pathological size amplifications like in `SmallVector<struct > {SmallVector<T, 4> a, b; }, 4>`, where the small s...

...;> >> > >>> >> >> > 2. avoiding pathological cases: The choice of N is usually >>> semi-arbitrary in our experience, and if one isn't careful, can result in >>> sizeof(SmallVector) becoming huge, especially in the case of nested >>> SmallVectors. This patch avoids pathological cases in two ways: >>> >> >> > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which >>> prevents pathological size amplifications like in `SmallVector<struct >>> {SmallVector<T, 4> a, b; }, 4...

...ng to read/write "N", or do an extra edit/recompile cycle if you forgot it > > 2. avoiding pathological cases: The choice of N is usually semi-arbitrary in our experience, and if one isn't careful, can result in sizeof(SmallVector) becoming huge, especially in the case of nested SmallVectors. This patch avoids pathological cases in two ways: > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which prevents pathological size amplifications like in `SmallVector<struct {SmallVector<T, 4> a, b; }, 4>`, where the small sizes effectively multiply togethe...

...o an extra edit/recompile cycle if you forgot it >> >> > >> >> > 2. avoiding pathological cases: The choice of N is usually semi-arbitrary in our experience, and if one isn't careful, can result in sizeof(SmallVector) becoming huge, especially in the case of nested SmallVectors. This patch avoids pathological cases in two ways: >> >> > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which prevents pathological size amplifications like in `SmallVector<struct {SmallVector<T, 4> a, b; }, 4>`, where the small sizes effectivel...

...it >> >> >> > >> >> >> > 2. avoiding pathological cases: The choice of N is usually >> semi-arbitrary in our experience, and if one isn't careful, can result in >> sizeof(SmallVector) becoming huge, especially in the case of nested >> SmallVectors. This patch avoids pathological cases in two ways: >> >> >> > A. SVec<T>'s heuristic keeps sizeof(SVec<T>) bounded, which >> prevents pathological size amplifications like in `SmallVector<struct >> {SmallVector<T, 4> a, b; }, 4>`, where...

>> 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 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. > > Something like this could definitely work, but most smallvectors are on the...

> On 2020 Nov 17, at 13:40, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, Nov 17, 2020 at 7:26 AM Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote: > On Nov 13, 2020, at 2:06 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> We've pretty

On Nov 13, 2020, at 2:06 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We've pretty happy now with a patch that adds two wrappers around SmallVector that make it 1) more convenient to use and 2) will tend to mitigate misuse of SmallVector. We think it's ready for wider discussion: https://reviews.llvm.org/D90884 <https://reviews.llvm.org/D90884> >

...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 `Twine::toNullTerminatedStringRef(SmallVectorImpl<char>&)` both use bytes outside the range of the SmallVectors storage. This isn't inherently bad. Secondly calling `SmallVectorImpl<T>::insert(iterator, const T&)` results in a reference invalidation when the element to insert is contained inside the SmallVector and the SmallVector needs to grow for the insert. This has been fixed inside the afo...

...ondot.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. They're all wild guesses, never profiled. Especially for vectors of relatively "large" elements, the pre-allocation optimization just doesn't make that much sense. I'd go as far as to suggest providing a default SmallVector N value of something like `siz...

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

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

....llvm.org/D48518 <https://reviews.llvm.org/D48518> (currently building with ASan to run check-llvm) and the surely uncontroversial https://reviews.llvm.org/D48516 <https://reviews.llvm.org/D48516>. > I think we might be better off just reducing the pre-allocation size of most of our SmallVectors across LLVM and Clang. They're all wild guesses, never profiled. Especially for vectors of relatively "large" elements, the pre-allocation optimization just doesn't make that much sense. I'd go as far as to suggest providing a default SmallVector N value of something like `siz...

While debugging a bootstrap problem, I noticed that SmallVector stores one element in SmallVectorImpl and N - 1 in SmallVector. It also assumes that all elements are continuous in memory. Does C++ makes any guaranties about the relative memory position of a base and parent classes? I haven't studied it a lot, maybe we can keep N elements in SmallVector and pass the pointer to SmallVectorImpl

Hello With LLVM 4.0 my code is being compiled correctly. but with LLVM 7.0.1 I am getting following error; *llvm-7.0.1.src/include/llvm/IR/Module.h:356:43: error: no matching constructor for initialization of 'SmallVector<llvm::Type *, sizeof...(ArgsTy)>' SmallVector<Type*, sizeof...(ArgsTy)> ArgTys{Args...};* What is the reason? Please help. Thank You