[llvm] Use llvm::bit_floor instead of llvm::PowerOf2Floor (NFC)

[Support] Reduce Dependence on Host.h

The intention behind this commit is to reduce the use of Host.h/Host.cpp
in Support, to where it is only necessary.

In this case, the endian-detection and supp

[Support] Reduce Dependence on Host.h

The intention behind this commit is to reduce the use of Host.h/Host.cpp
in Support, to where it is only necessary.

In this case, the endian-detection and support functionality needed by
these implementations can be provided by `Support/SwapByteOrder.h` in a
cleaner manner.

This patch also changes the byte swap in SHA256.cpp to use the byte swap
function from that header, rather than an inlined implementation.

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

show more ...

[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

[NFC] Move FoldingSetNodeIDRef::ComputeHash and FoldingSetNodeID::ComputeHash definitions to header

Lack of ComputeHash inlining slows down slightly FoldingSetBase::FindNodeOrInsertPos calls.
Inlini

[NFC] Move FoldingSetNodeIDRef::ComputeHash and FoldingSetNodeID::ComputeHash definitions to header

Lack of ComputeHash inlining slows down slightly FoldingSetBase::FindNodeOrInsertPos calls.
Inlining makes it faster which matters in particular for FoldingSet users in ASTContext.

Extracted from: https://reviews.llvm.org/D118385

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

show more ...

[NFC] Move FoldingSetNodeID::AddInteger and FoldingSetNodeID::AddPointer definitions to header

Lack of AddInteger/AddPointer inlining slows down NodeEquals/Profile/:operator== calls.
Inlining makes

[NFC] Move FoldingSetNodeID::AddInteger and FoldingSetNodeID::AddPointer definitions to header

Lack of AddInteger/AddPointer inlining slows down NodeEquals/Profile/:operator== calls.
Inlining makes FunctionProtoTypes/PointerTypes/ElaboratedTypes/ParenTypes Profile functions faster
but since NodeEquals is still called indirectly through function pointer from FindNodeOrInsertPos
there is room for further inlining improvements.

Extracted from: https://reviews.llvm.org/D118385

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

show more ...

[Support] FoldingSetNodeID::AddString(): reserve memory

Summary:
It is traditionally potentially very inefficient to not preallocate the memory,
but rely on reallocation every time you push somethin

[Support] FoldingSetNodeID::AddString(): reserve memory

Summary:
It is traditionally potentially very inefficient to not preallocate the memory,
but rely on reallocation every time you push something into vector.

For example, looking at unity build of RawSpeed
(`-O3 -g0 -emit-llvm -Xclang -disable-llvm-optzns`),
the memory story is as follows:
```
total runtime: 11.34s.
calls to allocation functions: 2694053 (237612/s)
temporary memory allocations: 645188 (56904/s)
peak heap memory consumption: 231.36MB
peak RSS (including heaptrack overhead): 397.39MB
```

Looking at details, `FoldingSetNodeID::AddString()` is noteworthy, frequently called and is allocation-heavy.

But it is quite obvious how many times we will push into `Bits` - we will push `String.size()` itself,
and then we will push once per every 4 bytes of `String` (padding last block).

And if we preallocate, we get:
```
total runtime: 11.20s.
calls to allocation functions: 2594704 (231669/s)
temporary memory allocations: 560004 (50000/s)
peak heap memory consumption: 231.36MB
peak RSS (including heaptrack overhead): 398.06MB
```
Which is a measurable win:
```
total runtime: -0.14s. # -1.23 %
calls to allocation functions: -99349 (719920/s) # -3.69 %
temporary memory allocations: -85184 (617275/s) # -13.2 % (!)
peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B
```

Reviewers: efriedma, nikic, bkramer

Reviewed By: bkramer

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...

Remove vptr dispatch from FoldingSet.

Summary:
Instead of storing a vptr in each FoldingSet instance, form an
equivalent struct and pass it implicitly from FoldingSet into the
various FoldingSetBase

Remove vptr dispatch from FoldingSet.

Summary:
Instead of storing a vptr in each FoldingSet instance, form an
equivalent struct and pass it implicitly from FoldingSet into the
various FoldingSetBase methods.

This has three benefits:
* FoldingSet becomes one pointer smaller.
* Under LTO, the "virtual" functions are much easier to inline.
* The element type no longer needs to be complete when instantiating
FoldingSet<T>, only when instantiating an insert / lookup member.

Reviewers: rnk

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

show more ...

Drop a StringMap.h include, NFC

$ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \
| grep '^[-+] ' | sort | uniq -c | sort -nr
231 - llvm/include/llvm/ADT/StringMap.h
17

Drop a StringMap.h include, NFC

$ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \
| grep '^[-+] ' | sort | uniq -c | sort -nr
231 - llvm/include/llvm/ADT/StringMap.h
171 - llvm/include/llvm/Support/AllocatorBase.h
142 - llvm/include/llvm/Support/PointerLikeTypeTraits.h

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

fix typos

llvm-svn: 342241

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338293

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

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

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] Reduce duplication between {Contextual,}FoldingSet; NFC

This is a precursor to another change (coming soon) that aims to make
FoldingSet's API more type-safe. Without this, the type-safety cha

[ADT] Reduce duplication between {Contextual,}FoldingSet; NFC

This is a precursor to another change (coming soon) that aims to make
FoldingSet's API more type-safe. Without this, the type-safety change
would just duplicate 4 more public methods between the already very
similar classes.

This renames FoldingSetImpl to FoldingSetBase so it's consistent with
the FooBase -> FooImpl<T> -> Foo<T> convention we seem to have with
other containers.

llvm-svn: 305231

show more ...

PR30711: Fix incorrect profiling of 'long long' in FoldingSet, then use it to
fix TBAA violation in profiling of pointers.

llvm-svn: 284336

Replace a few more "fall through" comments with LLVM_FALLTHROUGH

Follow up to r278902. I had missed "fall through", with a space.

llvm-svn: 278970

Adding reserve and capacity methods to FoldingSet

http://reviews.llvm.org/D20930

llvm-svn: 271669

[ADT] Teach FoldingSet to be movable.

This is a very minimal move support - it leaves the moved-from object in
a zombie state that is only valid for destruction and move assignment.
This seems fine

[ADT] Teach FoldingSet to be movable.

This is a very minimal move support - it leaves the moved-from object in
a zombie state that is only valid for destruction and move assignment.
This seems fine to me, and leaving it in the default constructed state
would require adding more state to the object and potentially allocating
memory (!!!) and so seems like a Bad Idea.

llvm-svn: 245192

show more ...

fix typos; NFC

llvm-svn: 234171