[Support] Add SpecificBumpPtrAllocator::identifyObject (#100475)

This already exists in BumpPtrAllocatorImpl, but I would like to use it
from SpecificBumpPtrAllocator.

I also noticed there was n

[Support] Add SpecificBumpPtrAllocator::identifyObject (#100475)

This already exists in BumpPtrAllocatorImpl, but I would like to use it
from SpecificBumpPtrAllocator.

I also noticed there was no test for identifyObject so I added one.

show more ...

[Support] Fix asan AllocatorTest after ba0d50ad7ec66

We were counting the number of bytes allocated, but under asan there's
extra redzone bytes by default. Disable this.

[Support] Fix UB in BumpPtrAllocator when first allocation is zero.

BumpPtrAllocator::Allocate() is marked __attribute__((returns_nonnull)) when the
compiler supports it, which makes it UB to return

[Support] Fix UB in BumpPtrAllocator when first allocation is zero.

BumpPtrAllocator::Allocate() is marked __attribute__((returns_nonnull)) when the
compiler supports it, which makes it UB to return null.

When there have been no allocations yet, the current slab is [nullptr, nullptr).
A zero-sized allocation fits in this range, and so Allocate(0, 1) returns null.

There's no explicit docs whether Allocate(0) is valid. I think we have to assume
that it is:
- the implementation tries to support it (e.g. >= tests instead of >)
- malloc(0) is allowed
- requiring each callsite to do a check is bug-prone
- I found real LLVM code that makes zero-sized allocations

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

show more ...

[Allocator] Make Deallocate() pass alignment and make it use (de)allocate_buffer

This lets it use sized deallocation and make more efficient alignment
decisions. Also adjust BumpPtrAllocator to alwa

[Allocator] Make Deallocate() pass alignment and make it use (de)allocate_buffer

This lets it use sized deallocation and make more efficient alignment
decisions. Also adjust BumpPtrAllocator to always allocate at
alignof(std::max_align_t).

show more ...

Reland "[llvm] Add a way to speed up the speed in which BumpPtrAllocator increases slab sizes""

Disable the red zone in the unit test allocator to fix the test errors in sanitizer builds.
The red zo

Reland "[llvm] Add a way to speed up the speed in which BumpPtrAllocator increases slab sizes""

Disable the red zone in the unit test allocator to fix the test errors in sanitizer builds.
The red zone changed the amount of allocated bytes which made the test fail as it
checked the number of allocated bytes of the allocator.

show more ...

Revert "[llvm] Add a way to speed up the speed in which BumpPtrAllocator increases slab sizes"

This reverts commit b848b510a8d52dbf50ee53a9a1ce844abb60d9bd as the unit tests
fail on the sanitizer bo

Revert "[llvm] Add a way to speed up the speed in which BumpPtrAllocator increases slab sizes"

This reverts commit b848b510a8d52dbf50ee53a9a1ce844abb60d9bd as the unit tests
fail on the sanitizer bots:
/b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/unittests/Support/AllocatorTest.cpp:145: Failure
Expected: SlabSize
Which is: 4096
To be equal to: Alloc.getTotalMemory()
Which is: 4097

show more ...

[llvm] Add a way to speed up the speed in which BumpPtrAllocator increases slab sizes

Summary:
In D68549 we noticed that our BumpPtrAllocator we use for LLDB's ConstString implementation is growing

[llvm] Add a way to speed up the speed in which BumpPtrAllocator increases slab sizes

Summary:
In D68549 we noticed that our BumpPtrAllocator we use for LLDB's ConstString implementation is growing its slabs at
a rate that is too slow for our use case. It causes that we spend a lot of time calling `malloc` for all the tiny slabs that our
ConstString BumpPtrAllocators create. We also can't just increase the slab size in the ConstString implementation
(which is what D68549 originally did) as this really increased the amount of (mostly unused) allocated memory
in any process using ConstString.

This patch adds a template argument for the BumpPtrAllocatorImpl that allows specifying a faster rate at which the
BumpPtrAllocator increases the slab size. This allows LLDB to specify a faster rate at which the slabs grow which
should keep both memory consumption and time spent calling malloc low.

Reviewers: george.karpenkov, chandlerc, NoQ

Subscribers: NoQ, llvm-commits, llunak

Tags: #llvm

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

show more ...

[Alignment][NFC] Move and type functions from MathExtras to Alignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pi

[Alignment][NFC] Move and type functions from MathExtras to Alignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 374773

show more ...

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 ne

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.

llvm-svn: 351636

show more ...

Report fatal error in the case of out of memory

This is the second part of recommit of r325224. The previous part was
committed in r325426, which deals with C++ memory allocation. Solution
for C mem

Report fatal error in the case of out of memory

This is the second part of recommit of r325224. The previous part was
committed in r325426, which deals with C++ memory allocation. Solution
for C memory allocation involved functions `llvm::malloc` and similar.
This was a fragile solution because it caused ambiguity errors in some
cases. In this commit the new functions have names like `llvm::safe_malloc`.

The relevant part of original comment is below, updated for new function
names.

Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.

In some cases memory is allocated by a call to some of C allocation
functions, malloc, calloc and realloc. They are used for interoperability
with C code, when allocated object has variable size and when it is
necessary to avoid call of constructors. In many calls the result is not
checked for null pointer. To simplify checks, new functions are defined
in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`.
They behave as corresponding standard functions but produce fatal error if
allocation fails. This change replaces the standard functions like 'malloc'
in the cases when the result of the allocation function is not checked
for null pointer.

Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statement is added.

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

llvm-svn: 325551

show more ...

Revert r325224 "Report fatal error in the case of out of memory"

It caused fails on some buildbots.

llvm-svn: 325227

Report fatal error in the case of out of memory

Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails

Report fatal error in the case of out of memory

Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.

Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".

There are calls to C allocation functions, malloc, calloc and realloc.
They are used for interoperability with C code, when allocated object has
variable size and when it is necessary to avoid call of constructors. In
many calls the result is not checked against null pointer. To simplify
checks, new functions are defined in the namespace 'llvm' with the
same names as these C function. These functions produce fatal error if
allocation fails. User should use 'llvm::malloc' instead of 'std::malloc'
in order to use the safe variant. This change replaces 'std::malloc'
in the cases when the result of allocation function is not checked against
null pointer.

Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statements are added.

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

llvm-svn: 325224

show more ...

[unittest] Explicitly specify alignment when using BumpPtrAllocator.

r297310 began inserting red zones around allocations under ASan, which
perturbs the alignment of subsequent allocations. Delibera

[unittest] Explicitly specify alignment when using BumpPtrAllocator.

r297310 began inserting red zones around allocations under ASan, which
perturbs the alignment of subsequent allocations. Deliberately specify
this in two places where it matters.

Fixes failures when these tests are run under ASan and UBSan together.
Reviewed by Duncan Exon Smith.

rdar://problem/30980047

llvm-svn: 297540

show more ...

Fix "the the" in comments.

llvm-svn: 240112

Fix llvm::BumpPtrAllocatorImpl::Reset()

BumpPtrAllocator's Reset wouldn't clear CustomSizedSlabs if Slabs.size() == 0.

Patch by Kal <b17c0de@gmail.com>!

llvm-svn: 237588

Try to unflake AllocatorTest.TestAlignmentPastSlab

llvm-svn: 217331

BumpPtrAllocator: do the size check without moving any pointers

Instead of aligning and moving the CurPtr forward, and then comparing
with End, simply calculate how much space is needed, and compare

BumpPtrAllocator: do the size check without moving any pointers

Instead of aligning and moving the CurPtr forward, and then comparing
with End, simply calculate how much space is needed, and compare that
to how much is available.

Hopefully this avoids any doubts about comparing addresses possibly
derived from past the end of the slab array, overflowing, etc.

Also add a test where aligning CurPtr would move it past End.

llvm-svn: 217330

show more ...

BumpPtrAllocator: use uintptr_t when aligning addresses to avoid undefined behaviour

In theory, alignPtr() could push a pointer beyond the end of the current slab, making
comparisons with that point

BumpPtrAllocator: use uintptr_t when aligning addresses to avoid undefined behaviour

In theory, alignPtr() could push a pointer beyond the end of the current slab, making
comparisons with that pointer undefined behaviour. Use an integer type to avoid this.

llvm-svn: 216973

show more ...

BumpPtrAllocator: don't accept 0 for the alignment parameter

It seems unnecessary to have to use an extra branch to check for this special case.

http://reviews.llvm.org/D4945

llvm-svn: 216036

BumpPtrAllocator: remove 'no slabs allocated yet' check

We already handle the no-slabs case when checking whether the current slab
is large enough: if no slabs have been allocated, CurPtr and End ar

BumpPtrAllocator: remove 'no slabs allocated yet' check

We already handle the no-slabs case when checking whether the current slab
is large enough: if no slabs have been allocated, CurPtr and End are both 0.
alignPtr(0), will still be 0, and so "if (Ptr + Size <= End)" fails.

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

llvm-svn: 215841

show more ...

[Allocator] Make BumpPtrAllocator movable and move assignable.

llvm-svn: 206372

[Allocator] Finally, finish nuking the redundant code that led me here
by removing the MallocSlabAllocator entirely and just using
MallocAllocator directly. This makes all off these allocators expose

[Allocator] Finally, finish nuking the redundant code that led me here
by removing the MallocSlabAllocator entirely and just using
MallocAllocator directly. This makes all off these allocators expose and
utilize the same core interface.

The only ugly part of this is that it exposes the fact that the JIT
allocator has no real handling of alignment, any more than the malloc
allocator does. =/ It would be nice to fix both of these to support
alignments, and then to leverage that in the BumpPtrAllocator to do less
over allocation in order to manually align pointers. But, that's another
patch for another day. This patch has no functional impact, it just
removes the somewhat meaningless wrapper around MallocAllocator.

llvm-svn: 206267

show more ...

[Allocator] Make the underlying allocator a template instead of an
abstract interface. The only user of this functionality is the JIT
memory manager and it is quite happy to have a custom type here.

[Allocator] Make the underlying allocator a template instead of an
abstract interface. The only user of this functionality is the JIT
memory manager and it is quite happy to have a custom type here. This
removes a virtual function call and a lot of unnecessary abstraction
from the common case where this is just a *very* thin vaneer around
a call to malloc.

Hopefully still no functionality changed here. =]

llvm-svn: 206149

show more ...

[Allocator] Switch the BumpPtrAllocator to use a vector of pointers to
slabs rather than embedding a singly linked list in the slabs
themselves. This has a few advantages:

- Better utilization of th

[Allocator] Switch the BumpPtrAllocator to use a vector of pointers to
slabs rather than embedding a singly linked list in the slabs
themselves. This has a few advantages:

- Better utilization of the slab's memory by not wasting 16-bytes at the
front.
- Simpler allocation strategy by not having a struct packed at the
front.
- Avoids paging every allocated slab in just to traverse them for
deallocating or dumping stats.

The latter is the really nice part. Folks have complained from time to
time bitterly that tearing down a BumpPtrAllocator, even if it doesn't
run any destructors, pages in all of the memory allocated. Now it won't.
=]

Also resolves a FIXME with the scaling of the slab sizes. The scaling
now disregards specially sized slabs for allocations larger than the
threshold.

llvm-svn: 206147

show more ...

[Allocator] Lift the slab size and size threshold into template
parameters rather than runtime parameters.

There is only one user of these parameters and they are compile time for
that user. Making

[Allocator] Lift the slab size and size threshold into template
parameters rather than runtime parameters.

There is only one user of these parameters and they are compile time for
that user. Making these compile time seems to better reflect their
intended usage as well.

llvm-svn: 205143

show more ...