config.host_os is derived from CMAKE_SYSTEM_NAME
which specifies the target. See:
https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html

To reduce confusion, rename it to config.target_os.

The variable name config.target_os was already being used by the Orc
tests. Rename it to config.orc_test_target_os with a FIXME to remove.

Reviewers: JDevlieghere, MaskRay

Reviewed By: MaskRay

Pull Request: https://github.com/llvm/llvm-project/pull/149015

Add naive implementation of memcpy, memset, memmove, memchr for SME
targets.
Co-authored-by: David Sherwood <david.sherwood@arm.com>

This reverts commit 3ab8d2aac7bc2dd45dda3db0b8a71fd27eefb749.

This change is causing issues running lit tests on many bots including:
- https://lab.llvm.org/buildbot/#/builders/197/builds/12119
- https://lab.llvm.org/buildbot/#/builders/184/builds/9792
- https://lab.llvm.org/buildbot/#/builders/93/builds/18455
- https://lab.llvm.org/buildbot/#/builders/231/builds/19858
- https://lab.llvm.org/buildbot/#/builders/121/builds/38426
- https://lab.llvm.org/buildbot/#/builders/230/builds/23990
- https://lab.llvm.org/buildbot/#/builders/57/builds/32391
- https://lab.llvm.org/buildbot/#/builders/247/builds/13502
- https://lab.llvm.org/buildbot/#/builders/275/builds/3601
- https://lab.llvm.org/buildbot/#/builders/269/builds/4211
- https://lab.llvm.org/buildbot/#/builders/18/builds/14161
- https://lab.llvm.org/buildbot/#/builders/19/builds/23893
- https://lab.llvm.org/buildbot/#/builders/37/builds/30295
- https://lab.llvm.org/buildbot/#/builders/77/builds/33979

Add naive implementation of memcpy, memset, memmove, memchr for SME
targets.
Co-authored-by: David Sherwood <david.sherwood@arm.com>

This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: jhenderson, #libc, Mordante, sivachandra

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

While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore.  `DyldNeedsEnvVariable()`
only returned true on macOS 10.10 and below.

Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain
that there truly is no fallout), but I decided to do this one because:

* I initially tricked myself into thinking that `MaybeReexec()` was
  relevant to my original investigation (instead of being dead code).
* The deleted code itself is quite complicated.
* Over time a few other things were mushed into `MaybeReexec()`:
  initializing `MonotonicNanoTime()`, verifying interceptors are
  working, and stripping the `DYLD_INSERT_LIBRARIES` env var to avoid
  problems when forking.
* This platform-specific thing leaked into `sanitizer_common.h`.
* The `ReexecDisabled()` config nob relies on the "strong overrides weak
  pattern", which is now problematic and can be completely removed.
* `ReexecDisabled()` actually hid another issue with interceptors not
  working in unit tests.  I added an explicit `verify_interceptors`
  (defaults to `true`) option instead.

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

Many tests for the `UBSan-Standalone-iossim-x86_64` fail with this.
Reverting so I can investigate.

This reverts commit 0a9667b0f56b1b450abd02f74c6175bea54f832e.

While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore.  `DyldNeedsEnvVariable()`
only returned true on macOS 10.10 and below.

Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain
that there truly is no fallout), but I decided to do this one because:

* I initially tricked myself into thinking that `MaybeReexec()` was
  relevant to my original investigation (instead of being dead code).
* The deleted code itself is quite complicated.
* Over time a few other things were mushed into `MaybeReexec()`:
  initializing `MonotonicNanoTime()`, verifying interceptors are
  working, and stripping the `DYLD_INSERT_LIBRARIES` env var to avoid
  problems when forking.
* This platform-specific thing leaked into `sanitizer_common.h`.
* The `ReexecDisabled()` config nob relies on the "strong overrides weak
  pattern", which is now problematic and can be completely removed.
* `ReexecDisabled()` actually hid another issue with interceptors not
  working in unit tests.  I added an explicit `verify_interceptors`
  (defaults to `true`) option instead.

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

On Darwin, we want to limit the parallelism during test execution for
sanitizer tests that use shadow memory.  The reason is explained by this
existing comment:

> Only run up to 3 processes that require shadow memory simultaneously
> on 64-bit Darwin. Using more scales badly and hogs the system due to
> inefficient handling of large mmap'd regions (terabytes) by the
> kernel.

Previously we detected 3 cases:
* on-device: limit to 1 process
* 64-bit: macOS & simulators, limit to 3 processes
* others (32-bit): no limitation

We checked for the 64-bit case like this: `if arch in ['x86_64',
'x86_64h']` which misses macOS running on AS. Additionally, we don't
care about 32-bit anymore, so I've simplified this to 2 cases: on-device
and everything else.

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