SmallVector::insert() fix

Chris Lattner clattner at apple.com
Fri Jun 14 12:02:45 PDT 2013


On Jun 10, 2013, at 12:02 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> I sent out the initial email several weeks ago and people got bit by this issue since then.
>> We could fix it and wait for C++11 adoption in the LLVM codebase, or move to one of Howard's proposal.
> 
> Yep.
> 
> The problem with Howard's proposals, it seems:
> 1) C++11 doesn't solve our "compiles as C++98" solution, and even if
> we were to adopt C++11 in the LLVM codebase, it probably wouldn't
> include C++ alias templates as MSVC doesn't support them so far as I
> know
> 2) Switching to std::vector with an explicit allocator is verbose at
> every call site
> 3) Switching to a type composed of std::vector with an explicit
> allocator is verbose in implementation - but we don't have to
> implement the entire std::vector API in the wrapper. Worst case we
> just implement whatever SmallVector already has (ideally pruning
> anything SmallVector has that std::vector doesn't, so that we can more
> easily switch to (1) when that becomes an option)

4) I have seen no numbers to back up the claim that it will be just as efficient.

SmallVector performance is important enough to the compiler that it really *is* worth duplicating code if we would otherwise regress on compile time.  Switching to use libc++ is both a non-goal, and not relevant for llvm on windows and other targets.

-Chris




More information about the llvm-commits mailing list