NFC.

For support calling conv in gisel, sharing code with BPFISelLowering.

Extra libraries can show up here depending on how LLVM was configured,
so just allow extra libraries to show up instead of expecting an exact
list.

Partially reverts d7aee330.

Buildbots reported:
.../CommandLine.cpp:1626:13: error: variable 'NearestHandler' set but not used [-Werror,-Wunused-but-set-variable]

This commit adds relative TableGen definitions to parse the
`[[gnu::no_stack_protector]]` attribute.

This PR addresses issue #75235.

The file name is WS2_32.Lib in all the Windows SDK versions I looked at.
You can get away with the incorrect casing on a case-insensitive file
system but it can matter for cross-compilation.

Summary:
More SPIR-V related patches are being upstreamed. We should add support
to detect when a binary file is SPIR-V. This will be used in the future
when support for SPIR-V is added to the offloading runtime or more
support for bundling.

The magic number is described in the official documentation:
https://registry.khronos.org/SPIR-V/specs/1.0/SPIRV.html#Magic. Notably,
SPIR-V files are streams of 32-bit words. This means that the magic
numbers differ depending on the endianness. Here we simply check the
strandard and byte-reversed versions.

My 632f1c appears to have missed a test update, sorry for the breakage.

The new attribute can be placed on statements in order to suppress
arbitrary warnings produced by static analysis tools at those statements.

Previously such suppressions were implemented as either informal comments
(eg. clang-tidy `// NOLINT:`) or with preprocessor macros (eg.
clang static analyzer's `#ifdef __clang_analyzer__`). The attribute
provides a universal, formal, flexible and neat-looking suppression mechanism.

Implement support for the new attribute in the clang static analyzer;
clang-tidy coming soon.

The attribute allows specifying which specific warnings to suppress,
in the form of free-form strings that are intended to be specific to
the tools, but currently none are actually supported; so this is also
going to be a future improvement.

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

This patch fixed the following compile error caused by #73603.

```
llvm/lib/Support/raw_ostream.cpp: In static member function ‘static llvm::Expected<llvm::ListeningSocket> llvm::ListeningSocket::createUnix(llvm::StringRef, int)’:
llvm/lib/Support/raw_ostream.cpp:1040:10: error: could not convert ‘ListenSocket’ from ‘llvm::ListeningSocket’ to ‘llvm::Expected<llvm::ListeningSocket>’
   return ListenSocket;
          ^~~~~~~~~~~~
```

If we know the exact VLEN, then we can tell if the AVL for particular
operation is equivalent to the vsetvli xN, zero, <vtype> encoding. Using
this encoding is better than having to materialize an immediate in a
register, but worse than being able to use the vsetivli zero, imm,
<type> encoding.

AF_UNIX sockets were added to Windows 10 build 17063 in 2017, older
versions of Windows will fail this test.

Also add a lit config so lit tests using sockets can do:
// REQUIRES: unix-sockets
(It would be cool if unit tests could use lit available_features)

Also fix llvm-config test that didn't fail when new libs are added.

The patch improves the reporting for the first option in the command
line when it looks like a subcommand name but does not match any
defined.

Before the patch:
```
> prog baz
prog: Unknown command line argument 'baz'.  Try: 'prog --help'
```

With the patch:
```
> prog baz
prog: Unknown subcommand 'baz'.  Try: 'prog --help'
prog: Did you mean 'bar'?
```

This patch defines BUILTIN_THREAD_POINTER in config.bzl when appropriate
on x86-64 linux only. This is needed to build exegesis properly as
certain functionality breaks if this is not enabled. This option is only
supported on relatively recent compiler versions, but given most people
using the bazel build are using very recent toolchains, this shouldn't
be an issue.

This PR adds a warning that's emitted when a non-streaming or
non-streaming-compatible builtin is called in an unsuitable function.

Uses work by Kerry McLaughlin.

`isDimOpValidSymbol` is used during the verification of `affine.for`
ops. It is used to check if LB/UB values are valid symbols. This change
adds support for `memref.cast`, which can be skipped over if it is a
ranked -> ranked cast.

This change fixes `mlir/test/Transforms/canonicalize.mlir`, which used
to fail when verifying the IR after each pattern application (#74270).
In this test case, a pattern that folds dynamic offsets/sizes/strides to
static ones is applied. This pattern inserts a trivial `memref.cast`
that can be folded away. This folding happens after the pattern
application, so the IR fails to verify after applying the
offsets/sizes/strides canonicalization pattern.

Note: The verifier of `affine.for` violates MLIR guidelines. Only local
properties of an op should be verified. The verifier should not inspect
the defining ops of operands. (This would mean that constraints such as
"operand is a valid affine symbol" cannot be verified.)

The current warning emitted by dsymutil when it can't find a symbol in
an object file is worded rather poorly:

```
could not find object file symbol for symbol _foo
```

It's also lacking information that makes the warning actionable, such as
the object file it's looking at. This patch rewords the warning and adds
the object file path to the warning:

```
could not find symbol '_foo' in object file 'test.o'
```

rdar://119621065

This is done for consistency with other sanitizers.
Also lock the allocator.

It's more meaningful and actionable to indicate which element in the
array has an issue by returning that element's index instead of its
value. The value can be ambiguous if at least one other element has the
same value.

The first parameter for these methods is `idxs`, an array of indices
that represent a path from a (root) parent to on of its descendants,
typically though intermediate descendants. When the path leads to a
descendant that doesn't exist, the method is supposed to indicate where
things went wrong by setting an index to `&index_of_error`, the second
parameter.

The problem is the method sets `*index_of_error` to the index of the
most recent parent's child in the hierarchy, which isn't very useful if
there's more one index with the same value in the path.

In this example, each element in the path has a value that's the same as
another element.

```cpp
GetChildAtIndexPath({1, 2, 3, 3, 1, 1, 2}, &index_of_error);
```

Say the the second `1` in the path (the 5th element at `[4]`) doesn't
exist and the code returns a `nullptr`. In that situation, the code sets
`*index_of_error` to `1`, but that's an ambiguous hint can implicate the
1st, 5th, or 6th element (at `[0]`, `[4]`, or `[5]`).

It’s more helpful to set `*index_of_error` to `4` to clearly indicate
which element in `idxs` has the issue.

Consistent include macro naming
Modified and added comments

It's not that I have much love for C++03, but we should ensure that it
works. Some recent changes broke this configuration because slightly
older Clang versions don't support attribute syntax in C++03 mode.

Lock Lsan and Thread related date at_fork.

Clean shadow before thread starts, forked process may reuse already
mapped stack of 'lost' parent thread for new threads.

Partial fix to https://github.com/openxla/iree/issues/15367

Pass the fully-qualified path name (less the file extension) of
git-clang-format.bat to py so that it can be run from anywhere.

Fixes #75265.

This reverts commit 87e2e890.
and its follow-ups 0d1490f0 (#75218)
and 6fe3cd54 (#75312).

We observed significant OOM/timeout issues due to #74670 to quite a few
services including google-research/swirl-lm. The follow-up #75218 and
 #75312 do not address the issue. Perhaps this is worth more
investigation.

The medium code model is basically identical to the small code model
except that large objects cannot be referenced with 32-bit offsets.

This prevents deadlocks in forked process
if parent had more then one running threads.

Simplifying an upcoming change...