sanitizer-ppc64le-linux is good while clang-ppc64le-linux has test
failures due to GetStaticTlsRange(addr, size) set *addr is 0.

Older watchOS SDKs *only* support i386 so we can't use x86_64/arm64
unconditionally.

This adds me as a Google representative for the LLVM security group.

This was proposed, discussed, and voted on in the differential revision
linked below; please see it for more information.

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

This keeps breaking on my machine. It's time to move on.

It's unlikely that FMADD and FMSUB would have different scheduling
information so merge them.

Reviewed By: HsiangKai

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

During context promotion, intermediate nodes that are on a call path but do not come with a profile can be promoted together with their parent nodes. Do not print sample context string for such nodes since they do not have profile.

Reviewed By: wenlei

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

Summary:
If the call to `synchronize` fails, it will currently block the stream indefinitely if execution is continued from this point. Additionally, if the program exits it will trigger an assertion on the non-null value of the async queue and prevent the runtime from printing debugging information.

Reviewers: jdoerfert

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

Now that NoTerminator is possible this op can be removed/it was only
needed structurally before. NFC.

Remove UpdateISAToDescriptorMapFromMemory because it's dead code.

This adds the consistency I promised in D99315 between how we read the
class info from the Objective-C runtime and the shared cache. (NFC)

Differential revision: https://reviews.llvm.org/D99446

The test is similar to the one used for LLD-ELF.

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

Summary: We needed to use `Joined` instead of `Flag`. This wasn't caught
because the relevant test that was copied from LLD-ELF was still
invoking LLD-ELF instead of LLD-MachO...

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

Pretty simple code-wise. Also threw in some refactoring:

* Put the functionStartSection under Writer instead of InStruct, since
  it doesn't need to be accessed outside of Writer
* Adjusted the test to put all files under the temp dir instead of at
  the top-level
* Added some CHECK-LABELs to make it clearer where the function starts
  data is

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

I've used IALU for the simplest operations from Zbb:
min, minu, max, maxu, sext.b, sext.h, zext.h, andn, orn, xnor

I've put add.uw in IALU32 and slli.uw in ShiftImm32.

Remaining instructions have received new classes.
All 3 sh*add are grouped together. sh*add.uw are grouped together.
Rotate left and right are together. Everything else got their own
class containing one instruction.

I think what I have here is the minimum granularity we need. I
could be convinced that we need more classes.

Reviewed By: evandro

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

Followup to: 0b1dc49c [NFC][OCaml] Resolve const and unsigned compilation warnings

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

The contents of the string returned by getenv() is not guaranteed across calls to getenv(). The code to handle the CC_PRINT etc env vars calls getenv() and saves the results in just a char *. The string returned by getenv() needs to be copied and saved. Switching the type of the strings from char * to std::string will do this and manage the alloated memory.

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

This reverts commit 166620a4.

A miscompile has been reported in https://reviews.llvm.org/D93927#2653480
and following.

Generic classes in Swift have their name instantiated on request, since
the vast majority never need it, and it just wastes time and memory.
This results in LLDB being unable to determine the dynamic type of these
Swift objects.

The main issues is that lazily named classes are not added to the
gdb_objc_realized_classes hashtable. This means the class count in the
table doesn't change when a class is realized and LLDB doesn't know it
needs to re-parse the class info. But even if it did, the classes are
not in the hash table.

The first change in this patch is that we read
objc_debug_realized_class_generation_count and re-parse the class info
when the count changes.

The second change in this patch is that we use
objc_copyRealizedClassList (if available) to get all realized classes
from the runtime.

Unfortunately, objc_copyRealizedClassList calls _dyld_objc_class_count
in its implementation. As we know, the Objective-C parsing code might
get called before dyld is fully initialized, resulting in crashes or
even a stranded lock. Therefore we only use objc_copyRealizedClassList
when we know it's safe to do so by checking libSystemInitialized in
dyld_all_image_infos.

As a result, it's possible that the first time we read the Objective-C
runtime we are forced to use gdb_objc_realized_classes. This should be
fine, as there should be no lazily named classes at this point.
Subsequent queries will detect the change in realized class generation
count and use objc_copyRealizedClassList.

This patch keeps the old behavior when objc_copyRealizedClassList or
objc_debug_realized_class_generation_count are not available.

Differential revision: https://reviews.llvm.org/D99315

Rather than including libc++ include dir, use the cxx-headers target.

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

`concept` is a reserved keyword in C++20, it can't be used as a variable name.
Here is an example of the failure:

```
      auto *concept = getInterfaceFor(op);
            ^
include/mlir/IR/SymbolInterfaces.h.inc:156:12: error: expected expression [clang-diagnostic-error]
      if (!concept)
           ^
```

Reviewed By: mehdi_amini

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

Things like addrspacecast may not be no-ops, so we should not look
through them.

Handle (x << s) != (y << s) where x != y and the shifts are
non-wrapping. Once again, this establishes parity with the
corresponing mul fold that already exists. The shift case is
more powerful because we don't need to guard against multiplies
by zero.

This handles the pattern X != X << C for non-zero X and C and a
non-overflowing shift. This establishes parity with the corresponing
fold for multiplies.

IR values convert to check prefix FileCheck variables for IR checks. For example, nameless values, e.g., %0, convert to check prefix TMP FileCheck variables, e.g., [[TMP0:%.*]]. This check prefix may clash with named values that have the same name and that causes auto-generated tests to fail. Currently a warning is emitted to change the names of the IR values but this is not always possible, if for example they are generated by clang. Manual intervention to fix the FileCheck variable names is too tedious. This patch add a parameter to prefix conflicting FileCheck variable names with a user-provided string to automate the process.

Reviewed By: jdoerfert

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

With D98926, many_tls_keys_pthread.cpp appears to be working.

On glibc 2.30-0ubuntu2, swapcontext.cpp and Linux/fork_and_leak.cpp work fine
but they strangely fail on clang-cmake-aarch64-full
(https://lab.llvm.org/buildbot/#/builders/7/builds/2240).
Disable them for now.

Note: check-lsan was recently enabled on AArch64 in D98985. A test takes
10+ seconds. We should figure out the bottleneck.

Add coverage for pointercasts other than bitcast. addrspacecast are not
handled properly at the moment.

In this case we don't care about the step at all, and only require
that the starting value is non-zero.

This is mainly for clarity: It doesn't make sense to do any
negative/positive checks when dealing with a nuw add/mul. These
only make sense to nsw add/mul.

Peek through bitcasts to find subvector splits and use getTargetShuffleInputs to decode target shuffles as well as ShuffleVectorSDNode

Option seems to be unsupported on the buildbot version
of OCaml. So expand the statements using a match.

Fixes buildbot failure due to
https://github.com/llvm/llvm-project/commit/c244cd72172ca8941f9f67fc183ade8afcd61c17