17 Commits

Author SHA1 Message Date
Chandler Carruth
6b547686c5 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-19 08:50:56 +00:00
Duncan P. N. Exon Smith
d61e7c7236 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337820 91177308-0d34-0410-b5e6-96231b3b80d8
2018-07-24 11:32:13 +00:00
Duncan P. N. Exon Smith
604b45ddcf 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337514 91177308-0d34-0410-b5e6-96231b3b80d8
2018-07-20 00:44:58 +00:00
Duncan P. N. Exon Smith
0ee7ae5caa 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337511 91177308-0d34-0410-b5e6-96231b3b80d8
2018-07-20 00:09:56 +00:00
Duncan P. N. Exon Smith
b3e4684b35 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337504 91177308-0d34-0410-b5e6-96231b3b80d8
2018-07-19 22:29:47 +00:00
Duncan P. N. Exon Smith
d417685a32 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335421 91177308-0d34-0410-b5e6-96231b3b80d8
2018-06-23 18:39:44 +00:00
Serge Pavlov
c71a2123c7 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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334344 91177308-0d34-0410-b5e6-96231b3b80d8
2018-06-09 05:19:45 +00:00
Serge Pavlov
d8472b591c 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333518 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-30 09:01:12 +00:00
Serge Pavlov
70fe1686ce 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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333506 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-30 05:13:19 +00:00
Serge Pavlov
d3b4e81711 Reverted commits 333390, 333391 and 333394
Build of shared library LLVMDemangle.so fails due to dependency problem.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333395 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-29 07:05:41 +00:00
Serge Pavlov
5c9fd60f9f 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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333390 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-29 05:39:08 +00:00
Matthias Braun
01337d5a14 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308576 91177308-0d34-0410-b5e6-96231b3b80d8
2017-07-20 01:30:39 +00:00
Daniel Sanders
07ce69ae7d [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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239392 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-09 09:47:46 +00:00
Richard Smith
bc36393108 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162331 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-22 00:11:07 +00:00
John McCall
2a9a2dba4c 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112870 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-02 21:55:03 +00:00
Benjamin Kramer
d164d3d9e7 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105605 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-08 11:44:30 +00:00
Chris Lattner
b3649db102 now that libsystem no longer uses SmallVector, we can move
SmallVectorBase::grow_pod out of line, finally satisfying PR3758.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91529 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-16 08:44:24 +00:00