Add `llvm::uninitialized_copy` that accepts a range instead of start/end
iterator for the source of the copy.

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

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

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

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

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

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

$ 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

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