[Support] Add some missing namespace closure comments. NFCI.

Fixes some clang-tidy warnings.

Revert "[Support] Explicitly instantiate BumpPtrAllocatorImpl"

This reverts commit add95990508ee0aec90d07bcce1bba47b4f46622.

Buildbots don't seem to like it.

[Support] Explicitly instantiate BumpPtrAllocatorImpl

Most clients only ever use the default BumpPtrAllocator.

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

Recover some overzealously removed includes.

llvm-svn: 320648

Remove redundant includes from lib/Support.

llvm-svn: 320627

Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)

Apparently, the style needs to be agreed upon first.

llvm-svn: 240390

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-c

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137

show more ...

Purge unused includes throughout libSupport.

NFC.

llvm-svn: 232976

[Allocator] Hoist the external helper function into a namespace scope
declaration. GCC 4.7 appears to get hopelessly confused by declaring
this function within a member function of a class template.

[Allocator] Hoist the external helper function into a namespace scope
declaration. GCC 4.7 appears to get hopelessly confused by declaring
this function within a member function of a class template. Go figure.

llvm-svn: 206152

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

[C++11] Replace some comparisons with 'nullptr' with simple boolean checks to reduce verbosity.

llvm-svn: 205829

[C++11] Make use of 'nullptr' in the Support library.

llvm-svn: 205697

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

[Allocator Cleanup] Move generic pointer alignment helper out of an
out-of-line private static method and into the collection of inline
alignment helpers in MathExtras.h.

llvm-svn: 204995

[Allocator Cleanup] Make the growth of the "slab" size of the
BumpPtrAllocator significantly less strange by making it a simple
function of the number of slabs allocated rather than by making it
a re

[Allocator Cleanup] Make the growth of the "slab" size of the
BumpPtrAllocator significantly less strange by making it a simple
function of the number of slabs allocated rather than by making it
a recurrance. I *think* the previous behavior was essentially that the
size of the slabs would be doubled after the first 128 were allocated,
and then doubled again each time 64 more were allocated, but only if
every allocation packed perfectly into the slab size. If not, the wasted
space wouldn't be counted toward increasing the size, but allocations
over the size threshold *would*. And since the allocations over the size
threshold might be much larger than the slab size, this could have
somewhat surprising consequences where we rapidly grow the slab size.

This currently requires adding state to the allocator to track the
number of slabs currently allocated, but that isn't too bad. I'm
planning further changes to the allocator that will make this state fall
out even more naturally.

It still doesn't fully decouple the growth rate from the allocations
which are over the size threshold. That fix is coming later.

This specific fix will allow making the entire thing into a more
stateless device and lifting the parameters into template parameters
rather than runtime parameters.

llvm-svn: 204993

show more ...

[BumpPtrAllocator] Move DefaultSlabAllocator to a member of BumpPtrAllocator, instead of a static variable.

The problem with having DefaultSlabAllocator being a global static is that it is undefined

[BumpPtrAllocator] Move DefaultSlabAllocator to a member of BumpPtrAllocator, instead of a static variable.

The problem with having DefaultSlabAllocator being a global static is that it is undefined if BumpPtrAllocator
will be usable during global initialization because it is not guaranteed that DefaultSlabAllocator will be
initialized before BumpPtrAllocator is created and used.

llvm-svn: 189433

show more ...

as the allocator is reset zero out the number of bytes allocated, this was just
missed before but probably what was intended.

llvm-svn: 175687

More MSan/ASan annotations.

This change lets us bootstrap LLVM/Clang under ASan and MSan. It contains
fixes for 2 issues:

- X86JIT reads return address from stack, which MSan does not know is
ini

More MSan/ASan annotations.

This change lets us bootstrap LLVM/Clang under ASan and MSan. It contains
fixes for 2 issues:

- X86JIT reads return address from stack, which MSan does not know is
initialized.
- bugpoint tests run binaries with RLIMIT_AS. This does not work with certain
Sanitizers.

We are no longer including config.h in Compiler.h with this change.

llvm-svn: 174306

show more ...

Annotate BumpPtrAllocator for MemorySanitizer.

This change adds MemorySanitizer annotations to BumpPtrAllocator to
improve report quality.

llvm-svn: 174051

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...

BumpPtrAllocator: Make sure threshold cannot be initialized with a value smaller than the slab size.

This replaces r151834 with a simpler fix.

llvm-svn: 151842

If BumpPtrAllocator is requested to allocate a size that exceeds the slab size,
increase the slab size.

llvm-svn: 151834

Add BumpPtrAllocator::getTotalMemory() to allow clients to query how much memory a BumpPtrAllocator allocated.

llvm-svn: 129727