This reverts commit 5e6bed8c0ea2f7fe380127763c8f753adae0fc1b while investigating the bots.

This is next in my series of "fix the racey tests that fail on
greendragon" addressing the failure of TestConcurrentManyBreakpoints.py
where we set a breakpoint in a function that 100 threads execute, and we
check that we hit the breakpoint 100 times. But sometimes it is only hit
99 times, and the test fails.

When we hit a software breakpoint, the pc value for the thread is the
address of the breakpoint instruction - as if it had not been hit yet.
And because a user might ADD a breakpoint for the current pc from the
commandline, when we go to resume execution, any thread that is sitting
at a breakpoint site will be silently advanced past the breakpoint
instruction (disable bp, instruction step that thread, re-enable bp)
before resuming -- whether that thread has hit its breakpoint or not.

What this test is exposing is that there is another corner case, a
thread that is sitting at a breakpoint site but has not yet executed the
breakpoint instruction. The thread will have no stop reason, no mach
exception, so it will not be recorded as having hit the breakpoint
(because it hasn't yet). But when we resume execution, because it is
sitting at a breakpoint site, we advance past it and miss the breakpoint
hit.

In 2016 Abhishek Aggarwal handled a similar issue with a patch in
`ProcessGDBRemote::SetThreadStopInfo()`, adding a breakpoint StopInfo
for a thread sitting at a breakpoint site that has no stop reason.
debugserver's `jThreadsInfo` would not correctly execute Abhishek's code
though because it would respond with `"reason":"none"` for a thread with
no stop reason, and `SetThreadStopInfo()` expected an empty reason here.
The first part of my patch is to clear the `reason` if it is `"none"` so
we flow through the code correctly.

On Darwin, though, our stop reply packet (Txx...) includes the
`threads`, `thread-pcs`, and `jstopinfo` keys, which give us the tids
for all current threads, the pc values for those threads, and
`jstopinfo` has a JSON dictionary with the mach exceptions for all
threads that have a mach exception. In
`ProcessGDBRemote::CalculateThreadStopInfo()` we set the StopInfo for
each thread for a private stop and if we have `jstopinfo` it is the
source of all the StopInfos. I have to add the same logic here, to give
the thread a breakpoint StopInfo even though it hasn't executed the
breakpoint yet. In this case we are very early in thread construction
and I only have the information in the Txx stop reply packet -- tids,
pcs, and jstopinfo, so I can't use the normal general mechanisms of
going through the RegisterContext to get the pc, it's a bit different.

If I hack debugserver to not issue `jstopinfo`,
`CalculateThreadStopInfo` will fall back to sending `qThreadStopInfo`
for each thread and going through
`ProcessGDBRemote::SetThreadStopInfo()` to set the stop infos (and with
the `reason:none` fix, use Abhishek's code).

rdar://110549165

Summary:
There are a lot of random training spaces on various lines. This patch
just got rid of all of them with `sed 's/\ \+$//g'.

Looking ast the definition of both functions this is *almost* an NFC
change, except that Triple also looks at the SubArch (important) and
ObjectFormat (less so).

This fixes a bug that only manifests with how Xcode uses the SBAPI to
attach to a process by name: it guesses the architecture based on the
system. If the system is arm64 and the Process is arm64e Target fails to
update the triple because it deemed the two to be equivalent.

rdar://123338218

[OpenMP][MLIR][OMPIRBuilder] Add a small optional constant alloca raise function pass to finalize, utilised in convertTarget (#78818)

This patch seeks to add a mechanism to raise constant (not ConstantExpr
or runtime/dynamic) sized allocations into the entry block for select
functions that have been inserted into a list for processing. This
processing occurs during the finalize call, after OutlinedInfo regions
have completed. This currently has only been utilised for
createOutlinedFunction, which is triggered for TargetOp generation in
the OpenMP MLIR dialect lowering to LLVM-IR.

This currently is required for Target kernels generated by
createOutlinedFunction to avoid subsequent optimization passes doing
some unintentional malformed optimizations for AMD kernels (unsure if it
occurs for other vendors). If the allocas are generated inside of the
kernel and are not in the entry block and are subsequently passed to a
function this can lead to required instructions being erased or
manipulated in a way that causes the kernel to run into a HSA access
error.

This fix is related to a series of problems found in:
https://github.com/llvm/llvm-project/issues/74603

This problem primarily presents itself for Flang's HLFIR AssignOp
currently, when utilised with a scalar temporary constant on the RHS and
a descriptor type on the LHS. It will generate a call to a runtime
function, wrap the RHS temporary in a newly allocated descriptor (an
llvm struct), and pass both the LHS and RHS descriptor into the runtime
function call. This will currently be
embedded into the middle of the target region in the user entry block,
which means the allocas are also embedded in the middle, which seems to
pose
issues when later passes are executed. This issue may present itself in
other HLFIR operations or unrelated operations that generate allocas as
a by product, but for the moment, this one test case is the only
scenario I've found this problem.

Perhaps this is not the appropriate fix, I am very open to other
suggestions, I've tried a few others (at varying levels of the
flang/mlir compiler flow), but this one is the smallest and least
intrusive change set. The other two, that come to mind (but I've not
fully looked into, the former I tried a little with blocks but it had a
few issues I'd need to think through):

- Having a proper alloca only block (or region) generated for TargetOps
that we could merge into the entry block that's generated by
convertTarget's createOutlinedFunction.
- Or diverging a little from Clang's current target generation and using
the CodeExtractor to generate the user code as an outlined function
region invoked from the kernel we make, with our kernel arguments passed
into it. Similar to the current parallel generation. I am not sure how
well this would intermingle with the existing parallel generation though
that's layered in.

Both of these methods seem like quite a divergence from the current
status quo, which I am not entirely sure is merited for the small test
this change aims to fix.

…wering

Right now attributes like OpenMP version or target attributes for
offload are set after lowering in bbc. The flang frontend sets them
before lowering, making them available in the lowering process.

This change sets them before lowering in bbc as well.

A semantic error was raised in device subprogram like: 

```
attributes(global) subroutine devsubr2()
   real, shared :: rs
   rs = 1
end subroutine
```

Object with the SHARED attribute can be can be read or written by all
threads in the block.


https://docs.nvidia.com/hpc-sdk/archive/24.1/compilers/cuda-fortran-prog-guide/index.html#cfpg-var-qual-attr-shared

Object with the CONSTANT attribute cannot be declared in the host
subprogram.

It can be declared in a module or a device subprogram.

Adapt the semantic check to trigger the error in host subprogram.

Fixes #82557. APX specification states that the high bits found in REX2
used to encode GPRs can also be used to encode control and debug
registers, although all of them will #UD. Therefore, when disassembling
we reject attempts to create control or debug registers with a value of
16 or more.

See page 22 of the
[specification](https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html):

> Note that the R, X and B register identifiers can also address non-GPR
register types, such as vector registers, control registers and debug
registers. When any of them does, the highest-order bits REX2.R4,
REX2.X4 or REX2.B4 are generally ignored, except when the register being
addressed is a control or debug register. [...] The exception is that
REX2.R4 and REX2.R3 [*sic*] are not ignored when the R register
identifier addresses a control or debug register. Furthermore, if any
attempt is made to access a non-existent control register (CR*) or debug
register (DR*) using the REX2 prefix and one of the following
instructions:
“MOV CR*, r64”, “MOV r64, CR*”, “MOV DR*, r64”, “MOV r64, DR*”. #UD is
raised.

The invalid encodings are 64-bit only because `0xd5` is a valid
instruction in 32-bit mode.

Summary:
Recent changes to the `libc` project caused the headers to be installed
to `include/<triple>` for the GPU and the libraries to be in
`lib/<triple>`. This means we should automatically append these search
paths so they can be found by default. This allows the following to work
targeting AMDGPU.

```shell
$ clang foo.c -flto -mcpu=native --target=amdgcn-amd-amdhsa -lc <install>/lib/amdgcn-amd-amdhsa/crt1.o
$ amdhsa-loader a.out
```

Summary:
Recent patches have allowed us to treat these libraries as direct
builds. This makes it easier to simply build them to a single LLVM-IR
file. This matches the way these files are presented by the ROCm and
CUDA toolchains and makes it easier to work with.

Summary:
This directory is leftover from when we handled both AMDGPU and NVPTX in
the same build and merged them into a pseudo triple. Now the only thing
it contains is the RPC server header. This gets rid of it, but now that
it's in the base install directory we should make it clear that it's an
LLVM libc header.

Summary:
The GPU backends have restrictions on the kinds of initializers they can
produce. The use of BlockStore here currently breaks the backends
through the use of recursive initializers. This prevents it from
actually being included in any builds. This patchs changes it to just
use a fixed size of 64 slots .The chances of someone exceeding the 64
slots in practice is very, very low.

However, this is primarily a bandaid solution as a real solution will
need to use a lock free data structure to push work in parallel.
Currently the mutexes on the GPU build do nothing, so they only work if
the user guards the use themselves.

This will allow us to atomically swap out RingBuffer and StackDepot.

Patched into AOSP and ran debuggerd_tests.

Add error messages showing the missing filenames.

Currently, we only get 'No such file or directory' without any(!)
further info. This patch will (only upon ENOENT error) iterate over all
requested files and print which ones are actually missing.

Use the legacy non-ObjC rename logic when dealing with selectors that
have zero or one arguments. In addition, make sure we don't add an extra
`:` during the rename.

Add a few more tests to verify this works (thanks to @ahoppen for the
tests and finding this bug).

Akin to `llvm::PatternMatch` and `llvm::MIPatternMatch`, the
`llvm::SDPatternMatch` introduced in this patch provides a DSL-alike
framework to match SDValue / SDNode with a more succinct syntax.

remove some obsoleted APIs from the library that have been fully
replaced with actual direct IR codegen

The lowering bridge stores the evvironment defaults (passed to the
constructor) as a reference. In the call to the constructor in bbc, the
defaults were passed as `{}`, which creates a temporary whose lifetime
ends immediately after the call.

The flang driver passes a member of the compilation instance to the
constructor, which presumably remains alive long enough, so storing the
reference in the bridge is justified. To avoid the dangling reference,
create an actual object `envDefaults` in bbc.

Remove all the code that set and tested Res. Change all convert*
functions to return void since none of them can fail. getInstruction
only has one main point of failure, after all calls to tryDecodeInst
have failed.

The base case of these call InferPtrInfo. This is dangerous due to
#82657, but it turns out none of these are used.

It seemed best to reduce the surface area until these are needed.

'region' is not a term of art in OpenACC, so switch it to refer to
'Compute Construct', which is accurate/reflects the standard.

Correct llvm-reduce strictfp test to follow the rules documented in the
LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

This test needed the strictfp attribute added to function definitions.

Test changes verified with D146845.

Summary:
The GPU target has recently been changed to support standard `libc`
build rules. This means we should be able to build for it both in
`LLVM_ENABLE_PROJECTS` mode, or targeting the runtimes directory
directly as in the LLVM `libc` documentation. Previously this failed
because the version check on the compiler was too strict and the
`--target=` options were not being set on the link jobs unless in CMake
cross compiliation mode. This patch fixes those so the following config
should work now to build the GPU target directly if using NVPTX.

```
cmake ../runtimes -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang \
  -DLLVM_ENABLE_RUNTIMES=libc -DLLVM_RUNTIMES_TARGET=nvptx64-nvidia-cuda \
  -DLLVM_DEFAULT_TARGET_TRIPLE=nvptx64-nvidia-cuda \
  -DLIBC_HDRGEN_EXE=/path/to/hdrgen/libc-hdrgen \
  -DLLVM_LIBC_FULL_BUILD=ON -GNinja
```

Summary:
The AMDGPU target needs an external clock symbol so the driver can set
the frequency with the correct value. This was left over from the
previous implementation and I forgot to remove it when actually
implementing the timing utilities.

The diagnostic message had four format specifiers but only three
parameters. This patch adds what I assume to be the missing
parameter.

These are hoped to provide more convenient and less error prone
facilities to encode and decode fields than manually defined constants
and functions.

we would replace the alloca with tagp for debug instructions, then
replace it back with the original alloca. it's easier to just skip the
replacement.

Clean up unused member variable.

This is a follow-up to #82333. It is possible that the target block of a
`BlockTypeConversionRewrite` is detached, so the `MLIRContext` cannot be
taken from the block.

Target::SetArchitecture() does not necessarily set the triple that is
being passed in, and will unconditionally log the real architecture to
the log channel. By flipping the order between the log outputs, the
resulting combined log makes a lot more sense to read.

This patch enables translation of svpmov intrinsic to the correct
assembly instruction, instead of function call.

Related discussion:
https://github.com/llvm/llvm-project/pull/73908/files#r1414913030.

This change fixes #73547.

All SchedModel files have a line that looks like:

```
def SomeModel : SchedMachineModel;
let SchedModel = SomeModel in {
  ...
}
```

TableGen requires that all records defined within the top level `let`
must have a field `SchedModel` somewhere in their nested record
hierarchy (i.e. the record has a field `SchedModel : SchedMachineModel`
or recursively, one of its members has a field `SchedModel :
SchedMachineModel`).

Classes such as `SchedPredicate` have added a field `SchedModel :
SchedMachineModel`, even though the field is never used, just to supress
**errors** (not warnings) caused from having the top level let in the
model files. This decision was made to avoid having hundreds of the same
`let` statement littered in every scheduler model file.

The reason we have never seen an error for `SchedVar` before is because
`SchedVar` is never instantiated with a `def`. Instead, it is only
created as a value that is consumed by `SchedWriteVariant`:

```
... : SchedWriteVariant<[SchedVar<...>, SchedVar<...>]>;
```

There is a problem with this style of instantiation. In particular, the
problem arises as we try to take a class based approach to building
scheduler models. I will describe the problem from the bottom up.

The `LMULWriteResMXVariant` multiclass takes in a `SchedPredicateBase
Pred`. Today, the RISCVSchedSiFive7.td file defines `VLDSX0Pred` outside
the scope of any class. That means that `VLDSX0Pred` exists before
`LMULWriteResMXVariant` multiclass is instantiated. With this approach,
there is no error since the predicate is instantated in entirety before
the variant multiclass is instantiated. However, I have the intention to
move the definition of both the predicate and the variant multiclass
records inside a multiclass to factor out common parts between multiple
scheduler models.

I plan to have something like:

```
multiclass SiFive7Base<SiFive7BaseConfig c> {
  def VLDSX0Pred : ...;
  // Need defvar since record is prefixed with NAME.
  defvar VLDSX0Pred = !cast<...>(NAME # VLDSX0Pred);
  defm SiFive7 : LMULWriteResMXVariant<VLDSX0Pred>;
}

defm "SiFive7Version1" : SiFive7Base<SiFive7BaseConfig<...>>;
defm "SiFive7Version2" : SiFive7Base<SiFive7BaseConfig<...>>;
```

In this scheme, VLDSX0Pred is defined within the same multiclass
transaction that the `LMULWriteResMXVariant` is defined in. For some
reason, TableGen does not allow `Values` to reference records that were
created in the same parent record construction. If the `SchedVar` is not
a `def`, then it will not be able to find the record `NAME #
VLDSX0Pred`. Making it a def, allows TableGen to find `NAME #
VLDSX0Pred` in scope.

The simplest example of this is:

```
class A {}
class B<A a> { A x = a;}
class C<B b> { B y = b;}
multiclass D {
  def MyA : A;
  defvar aa = !cast<A>(NAME # MyA);
  // This works
  def : B<aa>;
  // This does not work because constructing B by value cannot find `NAME # MyA`
  // error: Undefined reference to record: 'MyA'
  def : C<B<aa>>;
  // To fix it, define it like such:
  def MyB : B<aa>;
  defvar bb = !cast<B>(NAME # MyB);
  def : C<bb>;
}
defm "" : D;
```

In summary, in order to use a class based approach to creating scheduler
resources to promote resusability, `SchedVar`s must be created using
defs instead of being instantiated by value so that it can resolve
records that were part of the instantiation of the parent record being
created. In order to do this without refactoring the top level `let`
statement that all scheduler model files use, we add an unused field
`SchedModel : SchedMachineModel` to `SchedVar`, similiar to what has
been done in `SchedPredicate`.

Like linux releases, export a tar.xz files containing most llvm tools,
including non toolchain utilities, llvm-config, llvm-link and others.

We do this by reconfiguring cmake one last time at the last step,
running the install target so we do not need to recompile anything.

Fix #51192
Fix #53052

Enables conversion between llvm.dbg.label and DPLabel.