Implements
- LWG3885 'op' should be in [zombie.names]

Reviewed By: #libc, philnik

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

This reverts commit fc6b1268.

The `getEnclosingRepetitiveRegion` functions walk the ancestor regions everytime which can be expensive especially when there are multiple regions inbetween. This commit adds a cache to the bufferization analysis to remember the result of the walk.

Reviewed By: springerm

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

Move the implementation of the `toString` function from
`llvm/Support/Error.h` to the source file, which allows us to move
`#include "llvm/ADT/StringExtras.h"` to the source file as well.

As `Error.h` is present in a large number of translation units this
means we are unnecessarily bringing in the contents of
`StringExtras.h` - itself a large file with lots of includes - and
slowing down compilation.

Also move the `#include "llvm/ADT/SmallVector.h"` directive to the
source file as it's no longer needed, but this does not give as much of
a benefit.

This reduces the total number of preprocessing tokens across the LLVM
source files in lib from (roughly) 1,920,413,050 to 1,903,629,230 - a
reduction of ~0.87%. This should result in a small improvement in
compilation time.

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

In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.

This is fixing all files missed in b0abd489.

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

This patch is a continuation of D154206. It introduces a fold for the
operation "uadd_sat(X, C) pred C2" where "C" and "C2" are constants. The
fold is:

uadd_sat(X, C) pred C2
=> (X >= ~C) || ((X + C) pred C2) -> when (UINT_MAX pred C2) is true
=> (X < ~C)  && ((X + C) pred C2) -> when (UINT_MAX pred C2) is false

This patch also generalizes the fold to work with any saturating
intrinsic as long as the saturating value is known.

Proofs: https://alive2.llvm.org/ce/z/wWeirP

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

Create test cases to test the fold for the expression pattern
'uadd_sat(X, C) pred C2'.

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

D150013 is to render -L for AMDGPU but updating tools::AddLinkerInputs is wrong
and causes many non-isCrossCompiling targets to have duplicate -L options
because they do `Args.AddAllArgs(CmdArgs, options::OPT_L);`.

Revert the change and add a `Args.AddAllArgs(CmdArgs, options::OPT_L);` instead.

-e has the LinkerInput flag (commit fcf8ada1)
and is rendered by AddLinkerInputs. We should remove duplicate rendering (e.g.,
`Args.AddAllArgs(CmdArgs, options::OPT_e)`).

This is a follow up to D154529 covering tests.

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

Currently amdgpu-arch tool detects AMD GPU by dynamically
loading HSA runtime shared library and using HSA API's,
which is not available on Windows.

This patch makes it work on Windows by dynamically loading
HIP runtime dll and using HIP API's.

Reviewed by: Matt Arsenault, Joseph Huber, Johannes Doerfert

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

Implement LWG3843 (std::expected<T,E>::value() & assumes E is copy constructible)
https://wg21.link/LWG3843

Reviewed By: #libc, ldionne

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

That way if the command crashes you still know what it was.

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

type_traits doesn't need to include __type_traits/noexcept_move_assign_container.h, so there is no include cycle from <limits> or <new>. Restore their includes of type_traits to preserve compatibility.

This reverts commit 2af6d79c.

Reviewed By: ldionne, #libc

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

The methods added by D154177 don't require the `symbolSet` parameter to be mutable nor to have the `SmallVectorImpl` type, so this commit changes them to accept `ArrayRef` instead: both for generality, and to make the non-mutation an explicit part of the API.

Reviewed By: aartbik, Peiming

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

Create generic predicates to check for a ZR among the possible register
operands.

Similer to: D153112, match shl (v, splat 1) to vwadd

Reviewed By: craig.topper

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

A kernel can be exited in a non-aligned fashion, so we cannot pretend it
always ends in an aligned barrier. Instead, we require an explicit
aligned barrier as we lack a divergence analysis at this point.

If the next or last synchronizing instruction was an aligned barrier,
the instruction is executed in an aligned region.

Return immediately in isFunctionDeclarationName() if the token is neither a
keyword nor an identifier.

I've been trying to track down this problem for a while and finally
found a small enough reproducer for a test. Reductions sometimes
produce text IR which does not parse, with errors such as

"error: wrong number of indexes, expected 9"

This appears to not happen with bitcode reduction, as the bitcode
reader seems to silently discard uselistorder when the sizes don't
match. I believe this is caused by dangling constants in the
LLVMContext, which is currently recycled between different reductions.

The implementation of BACKSPACE on a variable-length sequential formatted
file has a bug that prevents it from working on an empty record.

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

We found that in a special condition, the input callee `Samples` is null for `findExternalInlineCandidate`, which caused an ICE.

In some rare cases, call instruction could be changed after being pushed into inline candidate queue, this is because earlier inlining may expose constant propagation which can change indirect call to direct call. When this happens, we may fail to find matching function samples for the candidate later(for example if the profile is stale), even if a match was found when the candidate was enqueued.

See this reduced program:

file1.c:
```
 int bar(int x);

 int(*foo())()  {
  return bar;
 };

void func()
 {
     int (*fptr)(int);
     fptr = foo();
     a +=  (*fptr)(10);
 }
```
file2.c:
```
int bar(int x) { return x + 1;}
```

The two CALL: `foo` and `(*ptr)` are pushed into the queue at the beginning, say `foo` is hotter and popped first for inlining. During the inlining of `foo`, it performs the constant propagation for the function pointer `bar` and then changed `(*ptr)` to a direct call `bar(..)`. Note that at this time, `(*ptr)/bar` is still in the queue, later while it's popped out for inlining, it use the a different target name(bar) to look for the callee samples. At the same time, if the profile is stale and the new function is different from the old function in the profile, then this led the return of the null callee sample.

Reviewed By: hoy, wenlei

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

dyld has two notification functions - a native one, and one that
it rewrites its arguments for, for lldb.  We currently use the
latter, _dyld_debugger_notification.  The native notification
function, lldb_image_notifier (and on older systems, gdb_image_notifier)
we can find by name, or if libdyld shows no dyld loaded in the
process currently, we can get it from the dyld_all_image_infos
object in memory which we can find with a system call.  When we do
a "waitfor attach" to a process on a modern darwin system, there
is a transition early in launch from the launch dyld to the
shared-cache-dyld, and when we attach in the middle of that transition,
libdyld will say there is no dyld present.  But we can still find
the in-memory dyld_all_image_infos which has the address of the
shared cache notifier function that will be registered in the
process soon.

This change will result in a much more reliable waitfor-attach.

This is the third landing of this patch.  We have an Intel mac
CI bot that is running an older (c. 2019) macOS 10.15, I had to
reproduce that environment and found the name of the notifier
function had changed which was the cause of those failures.

Differential Revision: https://reviews.llvm.org/D139453
rdar://101194149

Reviewed By: aartbik

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

This reverts commit 147c0640 since
it broke GPU builds.

Summary:
These were overriding rather than appending. Fix that.

We forgot to include the header, which means that _LIBCPP_USE_ULOCK was
always undefined and we'd always use the fallback. Note that this doesn't
seem to fix https://github.com/llvm/llvm-project/issues/63737.

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

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

A few __fwd includes are missing from public modules that will become noticeable when the private submodules are split into their own top level modules (D144322). Add the missing includes.

Reviewed By: ldionne, philnik, #libc

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

This is an alternate approach to the patches proposed in D153897 and
D153794. Rather than exporting a single header that can be included on
the GPU in all circumstances, this patch chooses to instead generate a
separate set of headers that only provides the declarations. This can
then be used by external tooling to set up what's on the GPU. This
leaves room for header hacks for offloading languages without needing to
worry about the `libc` implementation.

Currently this generates a set of headers that only contain the
declarations. These will then be installed to a new clang resource
directory called `llvm_libc_wrappers/` which will house the shim code.
We can then automaticlaly include this from `clang` when offloading to
wrap around the headers while specifying what's on the GPU.

Reviewed By: jdoerfert, JonChesterfield

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