search for: smallvector

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 SVec<T> is a convenience alias for SmallVector<T, N> with N chosen automatically to keep its size under 64 Bytes (tha...

...2:55 PM David Blaikie <dblaikie at gmail.com> wrote: > I will say I'm not a huge fan of adding even more names for things in > this fairly core/common use case (now we'll have even more vector > names to pick from) - can we use default template arguments so we can > write SmallVector<T> instead of SmallVector<T, N> and would that > address some of the use cases proposed here? > I won't claim it is perfect, but the added names are a compromise over rounds of reviews with the folks in the revision. In particular I'm quite concerned that a default value...

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 it's ready for wider discussion: > https://reviews.llvm.org/D90884 > > SVec<T> is a convenience alias for SmallVector<T, N> with N chosen > automatically to keep its...

...t; wrote: > >> > >> I will say I'm not a huge fan of adding even more names for things in > >> this fairly core/common use case (now we'll have even more vector > >> names to pick from) - can we use default template arguments so we can > >> write SmallVector<T> instead of SmallVector<T, N> and would that > >> address some of the use cases proposed here? > > > > > > I won't claim it is perfect, but the added names are a compromise over > rounds of reviews with the folks in the revision. In particular I'm...

...t;dblaikie at gmail.com> wrote: >> >> I will say I'm not a huge fan of adding even more names for things in >> this fairly core/common use case (now we'll have even more vector >> names to pick from) - can we use default template arguments so we can >> write SmallVector<T> instead of SmallVector<T, N> and would that >> address some of the use cases proposed here? > > > I won't claim it is perfect, but the added names are a compromise over rounds of reviews with the folks in the revision. In particular I'm quite concerned that a d...

...; >> I will say I'm not a huge fan of adding even more names for things in > >> >> this fairly core/common use case (now we'll have even more vector > >> >> names to pick from) - can we use default template arguments so we can > >> >> write SmallVector<T> instead of SmallVector<T, N> and would that > >> >> address some of the use cases proposed here? > >> > > >> > > >> > I won't claim it is perfect, but the added names are a compromise > over rounds of reviews with the folks in...

...ding even more names for things >>> in >>> >> >> this fairly core/common use case (now we'll have even more vector >>> >> >> names to pick from) - can we use default template arguments so we >>> can >>> >> >> write SmallVector<T> instead of SmallVector<T, N> and would that >>> >> >> address some of the use cases proposed here? >>> >> > >>> >> > >>> >> > I won't claim it is perfect, but the added names are a compromise >>>...

I will say I'm not a huge fan of adding even more names for things in this fairly core/common use case (now we'll have even more vector names to pick from) - can we use default template arguments so we can write SmallVector<T> instead of SmallVector<T, N> and would that address some of the use cases proposed here? I think someone (JYKnight, perhaps) mentioned in the code review (always difficult fragmenting the discussion between code review and RFC, unfortunately - not sure there's a great solution t...

...gt;> >> >> I will say I'm not a huge fan of adding even more names for things in >> >> this fairly core/common use case (now we'll have even more vector >> >> names to pick from) - can we use default template arguments so we can >> >> write SmallVector<T> instead of SmallVector<T, N> and would that >> >> address some of the use cases proposed here? >> > >> > >> > I won't claim it is perfect, but the added names are a compromise over rounds of reviews with the folks in the revision. In particu...

...not a huge fan of adding even more names for things >> in >> >> >> this fairly core/common use case (now we'll have even more vector >> >> >> names to pick from) - can we use default template arguments so we >> can >> >> >> write SmallVector<T> instead of SmallVector<T, N> and would that >> >> >> address some of the use cases proposed here? >> >> > >> >> > >> >> > I won't claim it is perfect, but the added names are a compromise >> over rounds of revie...

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

...er <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 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> >> >> SVec<T> is a convenience alias for SmallVector<T, N> with N...

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> > > SVec<T> is a convenience alias for SmallVector<T, N> with N chosen...

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

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

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 crash occurs only with clan...

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; > I've noticed that Clang is using more stack recently (we're seeing more crashes from template recursion; it seems the template recursion limit needs to shrink), and somehow that train of thought led to this. > > I share your skepticism that it will help stack usage much, but SmallVector/SmallVectorImpl is so ubiquitous, it could help the heap a bit. And if it doesn’t hurt runtime performance in practice, there’s no reason to fork the data structure. > > If no one has measured before I might try it some time. > > I think it's important to keep begin(), end(), an...

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

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2019011...