Breaks https://lab.llvm.org/buildbot/#/builders/5/builds/38700

This reverts commit c43c8850.

This pass isn't used anywhere upstream and thus has no test coverage.
For these reasons, remove it.

I recently moved from using vim to lunarvim. I noticed that `gcc` (lol)
wasn't able to comment out lines, because commentstring is not set.

Thanks to Chase Colman for the suggestion in
https://github.com/LunarVim/LunarVim/issues/4394.

std::hash and ADT/Hashing::hash_value are non-deterministic functions
whose
results might vary across implementation/process/execution. Using xxh3
instead
for computing hashes of BinaryFunctions and BinaryBasicBlock for stale
profile
matching.
(A possible alternative is to use ADT/StableHashing.h based on FNV
hashing but
xxh3 seems to be more popular in LLVM)

This is to address https://github.com/llvm/llvm-project/issues/65241.

This sanitizes the string for printing.

This is the first in a planned patch series to teach our vector lowering
how to exploit register boundaries in LMUL>1 types when VLEN is known to
be an exact constant. This corresponds to code compiled by clang with
the -mrvv-vector-bits=zvl option.

For extract_vector_elt, if we have a constant index and a known vlen,
then we can identify which register out of a register group is being
accessed. Given this, we can do a sub-register extract for that
register, and then shift any remaining index.

This results in all constant index extracts becoming m1 operations, and
thus eliminates the complexity concern for explode-vector idioms at high
lmul.

The "Dim" prefix is a legacy left-over that no longer makes sense, since
we have a very strict "Dimension" vs. "Level" definition for sparse
tensor types and their storage.

This adds functionality to tbd files similar to what `lipo -extract`
and `lipo -remove` does for binaries.

Summary:
These tests are currently failing, disable them so we can keep the bots
green until we find a better solution. The x64 tests are not the core
target so this is low priority.

In the FreeBSD base system, re-executing the main binary when ASLR is
detected was implemented in the following commits:

* freebsd/freebsd-src@7cafe89f9ce33
* freebsd/freebsd-src@96fe7c8ab0f65
* freebsd/freebsd-src@930a7c2ac67e1
* freebsd/freebsd-src@0a736f0a6aeb0
* freebsd/freebsd-src@4c9a0adad1826

Squash all these to bring them into upstream compiler-rt.

When ASLR is detected to be enabled, this first force-disables ASLR for
the current process, then calls ReExec(). The ReExec() function gets a
FreeBSD specific implementation for finding the path of the executed
program, via the ELF auxiliary vector. This is done without calling into
the regular elf_aux_info(3) function, as that makes use of several
already-intercepted functions.

On macOS <vector> was already included via another
header file, but this failed on the CI bots.  I'd
tested on linux earlier in this patch's life when
the headers were differently arranged.

The previous optional class would call the destructor on a non-trivially
destructible object regardless of if it had already been reset. This
patch fixes this by moving tracking for if the object exists into the
internal storage class for optional.

This PR adds support for the PPA2 fields.

---------

Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>

This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.

This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.

There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.

This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.

This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.

To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.

I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.

There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).

"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.

I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.

I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.

https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

The primary difficulty with distribution of masked transfers is when the
permutation map permutes the vector, in which case the distribution
logic needs to make sure the correct mask elements end up with the
distributed transfer. This is only tricky when the permutation map has a
permutation in it, so we can relax the condition for distribution.

This is just a simple cleanup of hlsl_intrinsics.h. I've broken this
into two commits to make it easier to follow during review. The first
commit replaces the `__attribute__` annotations with preprocessor macros
to make it easier to read the function declarations. The second commit
sorts the function declarations.

Function declarations are sorted by function name alphabetically, then
grouped by base element type. The declarations within each group are
sorted in increasing order by number of elements, and the groups
themselves are sorted by increasing element size. For elements of the
same size they are then sorted by signed integers, then unsigned
integers then floating point.

The purpose of this example is to provide a case where the debugger /
debug info experience could be improved. A recent commit by clang
(0d2860b7) changed codegen such that it
changes how "small structs" are initialized, in a way that the debugger
is now able to correctly display the variable being targeted by this
test.

In order to keep the example relevant, i.e. failing, this commit makes
it so that the struct is now "big enough" to not trigger the new
codegen.

Closes #70451.

We can't set MO_PLT on an indirect call.
We need to constrain the register class for the operand to the call
instruction.

The disjoint flag was recently added to IR in #72583 

Lit features are evaluated in order. Some checks may require the
compiler detection to have run first in order to work properly, for
example some checks being added in https://reviews.llvm.org/D154246
which require GCC to have been detected. It is kind of brittle to rely
on such ordering, but in practice moving the compiler detection first
should never hurt.

Summary:
This option used to be passed manually by the `-fPIC` option that was
always enabled by the LLVM flags. Since we now do this manually we want
to specify that these are supposed for use fPIC code.

Summary:
We used to inherit these flags from the LLVM options in a runtimes
build. This patch adds them back in manually as they are helpful for
diagnostics and optimizing the created binary.

Looks like it broke the ASAN build: https://lab.llvm.org/buildbot/#/builders/168/builds/17053/steps/9/logs/stdio

This reverts commit f8afc53d.

Currently, there are a couple dead links in the comment surrounding the
tablegen implementtion of the GHC calling convention in AArch64. There
was some refactoring in GHC that moved things around. This patch fixes
up the comment to match the current state of the repository to make it
easier for future readers to reference the relevant documentation.

Summary:
There are a few default options that LLVM adds that can be problematic
for runtimes builds. These options are generally intended to handle
building LLVM itself, but are also added when building in a runtimes
mode. One such issue I've run into is that in `libc` we deliberately use
`--target` to use a different device toolchain, which doesn't support
some linker arguments passed via `-Wl`. This is observed in
https://github.com/llvm/llvm-project/pull/73030 when attempting to use
these options.

This patch completely removes these default arguments.

The consensus is that any issues created by this patch should ultimately
be solved on a per-runtime basis.

It otherwise fails on Windows.

There is no point in keeping GenericDeviceTy objects alive longer than
the associated GenericPluginTy. Instead of the old API we now tear them
down with the plugin, avoiding ordering issues.

I came across an undefined behavior when running Support unit tests with
UBSAN on Windows.
```bash
[ RUN      ] LEB128Test.SLEB128Size
C:\llvm\unittests\Support\LEB128Test.cpp:382:3: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long'; cast to an unsigned type to negate this value to itself
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior C:\llvm\unittests\Support\LEB128Test.cpp:382:3 in 
```

UBSAN did not report the same error on macOS, but the negation still
seemed invalid (`0x8000000000000000LL == -0x8000000000000000LL`
evaluated to `true`).
I can confirm that `-0x7fffffffffffffffLL - 1` results in the expected
value on both platforms.

512bit vpbroadcastw is available only with AVX512BW. Avoid lowering
BUILD_VEC into vbroard_cast node when the condition is not met. This
fixed a crash (see the added new test).

The order in which we deinit things, especially when shared libraries
are involved, is complicated. To simplify our lives the nextgen plugin
deinitializes the GenericPluginTy and subclasses automatically. The old
__tgt_rtl_deinit_plugin is not needed anymore.

These APIs have not been hooked up for a while. No need to carry them.

NFC processing time script identifies tests by output filename.
When `/dev/null` is used as output filename, we're unable to tell the
source test, and the reports are unhelpful.
Replace `/dev/null/` with `%t.null` which resolves the issue.