ADT: Shrink SmallVector size 0 to 16B on 64-bit platforms

SmallVectorTemplateCommon wants to know the address of the first element
so it can detect whether it's in "small size" mode.

The old implem

ADT: Shrink SmallVector size 0 to 16B on 64-bit platforms

SmallVectorTemplateCommon wants to know the address of the first element
so it can detect whether it's in "small size" mode.

The old implementation split the small array, creating the storage for
the first element in SmallVectorTemplateCommon, and pulling the rest
into SmallVectorStorage where we know the size of the array. This
bloats SmallVector size 0 by the larger of sizeof(void*) and sizeof(T),
and we're not even using the storage.

The new implementation leaves the full small storage to
SmallVectorStorage. To calculate the offset of the first element in
SmallVectorTemplateCommon, we just need to know how far to jump, which
we can calculate out-of-band. One subtlety is that we need
SmallVectorStorage to be properly aligned even when the size is 0, to be
sure that (for large alignments) we actually have the padding and it's
well defined to do the pointer math.

llvm-svn: 337820

show more ...

Reapply "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"

I'm optimistically reverting commit r337511, effectively reapplying
r337504 *without* changes.

The failing bots that had `SmallVe

Reapply "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"

I'm optimistically reverting commit r337511, effectively reapplying
r337504 *without* changes.

The failing bots that had `SmallVector` in the backtrace recovered after
the unrelated commit r337508. The backtraces looked bogus anyway, with
`SmallVector::size()` calling (e.g.) `ConstantArray::get()`.

Here's the original commit message:

ADT: Shrink size of SmallVector by 8B on 64-bit platforms

Represent size and capacity directly as unsigned and calculate
`end()` using `begin() + size()`.

This limits the maximum size/capacity of a vector to UINT32_MAX.

https://reviews.llvm.org/D48518

llvm-svn: 337514

show more ...

Revert "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"

This reverts commit r337504 while I investigate a TSan bot failure that
seems related:

http://lab.llvm.org:8011/builders/sanitizer

Revert "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"

This reverts commit r337504 while I investigate a TSan bot failure that
seems related:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/26526

#8 0x000055581f2895d8 (/b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang-7+0x1eb45d8)
#9 0x000055581f294323 llvm::ConstantAggrKeyType<llvm::ConstantArray>::create(llvm::ArrayType*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:409:0
#10 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::create(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>, std::pair<unsigned int, std::pair<llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray> > >&) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:635:0
#11 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::getOrCreate(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:654:0
#12 0x000055581f2944cb llvm::ConstantArray::get(llvm::ArrayType*, llvm::ArrayRef<llvm::Constant*>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/Constants.cpp:964:0
#13 0x000055581fa27e19 llvm::SmallVectorBase::size() const /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:53:0
#14 0x000055581fa27e19 llvm::SmallVectorImpl<llvm::Constant*>::resize(unsigned long) /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:347:0
#15 0x000055581fa27e19 (anonymous namespace)::EmitArrayConstant(clang::CodeGen::CodeGenModule&, clang::ConstantArrayType const*, llvm::Type*, unsigned int, llvm::SmallVectorImpl<llvm::Constant*>&, llvm::Constant*) /b/sanitizer-x86_64-linux-autoconf/build/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp:669:0

llvm-svn: 337511

show more ...

ADT: Shrink size of SmallVector by 8B on 64-bit platforms

Representing size and capacity directly as unsigned and calculate
`end()` using `begin() + size()`.

This limits the maximum size/capacity o

ADT: Shrink size of SmallVector by 8B on 64-bit platforms

Representing size and capacity directly as unsigned and calculate
`end()` using `begin() + size()`.

This limits the maximum size/capacity of a vector to UINT32_MAX.

https://reviews.llvm.org/D48518

llvm-svn: 337504

show more ...

ADT: Use EBO to shrink SmallVector size 1

SmallVectorStorage is empty when its size is 1; use inheritance so that
the empty base class optimization kicks in.

llvm-svn: 335421

Use uniform mechanism for OOM errors handling

This is a recommit of r333506, which was reverted in r333518.
The original commit message is below.

In r325551 many calls of malloc/calloc/realloc were

Use uniform mechanism for OOM errors handling

This is a recommit of r333506, which was reverted in r333518.
The original commit message is below.

In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
generate crash if memory cannot be allocated, such behavior facilitates
handling of out of memory errors on Windows.

If the result of *alloc function were checked for success, the function was
not replaced with the safe variant. In these cases the calling function made
the error handling, like:

T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T)));
if (NewElts == nullptr)
report_bad_alloc_error("Allocation of SmallVector element failed.");

Actually knowledge about the function where OOM occurred is useless. Moreover
having a single entry point for OOM handling is convenient for investigation
of memory problems. This change removes custom OOM errors handling and
replaces them with calls to functions `llvm::safe_*alloc`.

Declarations of `safe_*alloc` are moved to a separate include file, to avoid
cyclic dependency in SmallVector.h

Differential Revision: https://reviews.llvm.org/D47440

llvm-svn: 334344

show more ...

Revert commit 333506

It looks like this commit is responsible for the fail:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/24382.

llvm-svn: 333518

Use uniform mechanism for OOM errors handling

This is a recommit of r333390, which was reverted in r333395, because it
caused cyclic dependency when building shared library `LLVMDemangle.so`.
In thi

Use uniform mechanism for OOM errors handling

This is a recommit of r333390, which was reverted in r333395, because it
caused cyclic dependency when building shared library `LLVMDemangle.so`.
In this commit `ItaniumDemangler.cpp` was not changed.

The original commit message is below.

In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
generate crash if memory cannot be allocated, such behavior facilitates
handling of out of memory errors on Windows.

If the result of *alloc function were checked for success, the function was
not replaced with the safe variant. In these cases the calling function made
the error handling, like:

T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T)));
if (NewElts == nullptr)
report_bad_alloc_error("Allocation of SmallVector element failed.");

Actually knowledge about the function where OOM occurred is useless. Moreover
having a single entry point for OOM handling is convenient for investigation
of memory problems. This change removes custom OOM errors handling and
replaces them with calls to functions `llvm::safe_*alloc`.

Declarations of `safe_*alloc` are moved to a separate include file, to avoid
cyclic dependency in SmallVector.h

Differential Revision: https://reviews.llvm.org/D47440

llvm-svn: 333506

show more ...

Reverted commits 333390, 333391 and 333394

Build of shared library LLVMDemangle.so fails due to dependency problem.

llvm-svn: 333395

Use uniform mechanism for OOM errors handling

In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
genera

Use uniform mechanism for OOM errors handling

In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
generate crash if memory cannot be allocated, such behavior facilitates
handling of out of memory errors on Windows.

If the result of *alloc function were checked for success, the function was
not replaced with the safe variant. In these cases the calling function made
the error handling, like:

T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T)));
if (NewElts == nullptr)
report_bad_alloc_error("Allocation of SmallVector element failed.");

Actually knowledge about the function where OOM occurred is useless. Moreover
having a single entry point for OOM handling is convenient for investigation
of memory problems. This change removes custom OOM errors handling and
replaces them with calls to functions `llvm::safe_*alloc`.

Declarations of `safe_*alloc` are moved to a separate include file, to avoid
cyclic dependency in SmallVector.h

Differential Revision: https://reviews.llvm.org/D47440

llvm-svn: 333390

show more ...

Support, IR, ADT: Check nullptr after allocation with malloc/realloc or calloc

As a follow up of the bad alloc handler patch, this patch introduces nullptr checks on pointers returned from the
mallo

Support, IR, ADT: Check nullptr after allocation with malloc/realloc or calloc

As a follow up of the bad alloc handler patch, this patch introduces nullptr checks on pointers returned from the
malloc/realloc/calloc functions. In addition some memory size assignments are moved behind the allocation
of the corresponding memory to fulfill exception safe memory management (RAII).

patch by Klaus Kretzschmar

Differential Revision: https://reviews.llvm.org/D35414

llvm-svn: 308576

show more ...

[ADT] Assert that SmallVectorBase::grow_pod() successfully reallocates memory.

Summary:
If malloc/realloc fails then the SmallVector becomes unusable since begin() and
end() will return NULL. This i

[ADT] Assert that SmallVectorBase::grow_pod() successfully reallocates memory.

Summary:
If malloc/realloc fails then the SmallVector becomes unusable since begin() and
end() will return NULL. This is unlikely to occur but was the cause of recent
bugpoint test failures on my machine.

It is not clear whether not checking for malloc/realloc failure is a deliberate
decision and adding checks has the potential to impact compiler performance.
Therefore, this patch only adds the check to builds with assertions enabled for
the moment.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: bkramer, llvm-commits

Differential Revision: http://reviews.llvm.org/D9520

llvm-svn: 239392

show more ...

Reduce alignment of SmallVector<T> to the required amount, rather than forcing 16-byte alignment. This fixes misaligned SmallVector accesses via ExtractValueInst's SmallVector data member.

llvm-svn:

Reduce alignment of SmallVector<T> to the required amount, rather than forcing 16-byte alignment. This fixes misaligned SmallVector accesses via ExtractValueInst's SmallVector data member.

llvm-svn: 162331

show more ...

After some discussion with djg, teach SmallVector to grow from a zero
capacity and remove the workaround in SmallVector<T,0>. There are some
theoretical benefits to a N->2N+1 growth policy anyway.

After some discussion with djg, teach SmallVector to grow from a zero
capacity and remove the workaround in SmallVector<T,0>. There are some
theoretical benefits to a N->2N+1 growth policy anyway.

llvm-svn: 112870

show more ...

Use realloc instead of malloc+memcpy when growing a POD SmallVector. A smart
realloc implementation can try to expand the allocated memory block in-place,
avoiding the copy.

llvm-svn: 105605

now that libsystem no longer uses SmallVector, we can move
SmallVectorBase::grow_pod out of line, finally satisfying PR3758.

llvm-svn: 91529