On some architectures (currently gfx90a, gfx94*, and gfx10**), we can
implement an LDS barrier using compiler intrinsics instead of inline
assembly, improving optimization possibilities and decreasing the
fragility of the underlying code.

Other AMDGPU chipsets continue to require inline assembly to implement
this barrier, as, by the default, the LLVM backend will insert waits on
global memory (s_waintcnt vmcnt(0)) before barriers in order to ensure
memory watchpoints set by debuggers work correctly.

Use of amdgpu.lds_barrier, on these architectures, imposes a tradeoff
between debugability and performance. The documentation, as well as the
generated inline assembly, have been updated to explicitly call
attention to this fact.

For chipsets that did not require the inline assembly hack, we move to
the s.waitcnt and s.barrier intrinsics, which have been added to the
ROCDL dialect. The magic constants used as an argument to the waitcnt
intrinsic can be derived from
llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp

[libc++] Only forward-declare ABI-functions in exception_ptr.h if they are meant to be used (#84707)

This patch fixes the unconditional forward-declarations of ABI-functions
in exception_ptr.h, and makes it dependent on the availability macro, as
it should've been from the beginning.

The declarations being unconditional break the build with libcxxrt
before 045c52ce8 [1], now they are opt-out.

[1]: https://github.com/libcxxrt/libcxxrt/commit/045c52ce821388f4ae4d119fe4fb75f1eb547b85

The `parse.pass.cpp` tests doen't need to call
`test_format_context_create` to create a `basic_format_context`, so they
shouldn't include `test_format_context.h`.

The `to_address` mechanism works around the iterator debugging
mechanisms of MSVC STL. Related to
[LWG3989](https://cplusplus.github.io/LWG/issue3989).

Discovered when implementing `formatter<tuple>` in MSVC STL. With the
inclusion removed, `std/utilities/format/format.tuple/parse.pass.cpp`
when using enhanced MSVC STL (and `/utf-8` option for MSVC).

The prior naming scheme is incredibly hard to make sense out of. I
suspect the usage was actually backwards from intent - though that
didn't matter for any in tree schedule model.

Test failures fixed in d0117b71

Previously, we always used the wave64 encodings for EH registers
regardless of whether we were compiling for wave32, which seems wrong.
We don't seem to use the EH registers, so this commit is mostly just
about papering over code that converts from non-EH dwarf registers to
LLVM registers while claiming they are EH dwarf registers. That kind of
code should be okay on any non-darwin target (since darwin is the only
target that uses a different encoding for EH registers).

Fixes failing tests after https://github.com/llvm/llvm-project/pull/84308

LLVM :: CodeGen/AMDGPU/GlobalISel/irtranslator-non-integral-address-spaces-vectors.ll
LLVM :: CodeGen/AMDGPU/GlobalISel/irtranslator-non-integral-address-spaces.ll
LLVM :: CodeGen/AMDGPU/lower-buffer-fat-pointers-calls.ll
LLVM :: CodeGen/AMDGPU/lower-buffer-fat-pointers-constants.ll
LLVM :: CodeGen/AMDGPU/lower-buffer-fat-pointers-pointer-ops.ll
LLVM :: CodeGen/AMDGPU/pal-metadata-3.0.ll

Buildbots: https://lab.llvm.org/buildbot/#/builders/121/builds/39855

Someone pointed out a typo (Value* RsrcRes = RsrcRes = ...) in PR the
address space 7 lowering, this commit fixes it.

Re-land 634b0243.

T1 allow for an optional registers list,
the register list must be {d0-d15}.
T2 define a mandatory register list,
the register list must be {d0-d31}.

The requirements for T1/T2 are as follows:
                T1              T2
Require:        v8-M.Main,      v8.1-M.Main,
                secure state    secure state
16 D Regs       valid           valid
32 D Regs       UNDEFINED       valid
No D Regs       NOP             NOP

Summary:
The libc build has a few utilties that need to be built before we can do
everything in the full build. The one requirement currently is the
`libc-hdrgen` binary. If we are doing a full build runtimes mode we
first add `libc` to the projects list and then only use the `projects`
portion to buld the `libc` portion. We also use utilities for the GPU
build, namely the loader utilities. Previously we would build these
tools on-demand inside of the cross-build, which tool some hacky
workarounds for the dependency finding and target triple. This patch
instead just builds them similarly to libc-hdrgen and then passses them
in. We now either pass it manually it it was built, or just look it up
like we do with the other `clang` tools.

Depends on https://github.com/llvm/llvm-project/pull/84664

- Fixes: https://github.com/llvm/llvm-project/issues/82177
- Alive2: https://alive2.llvm.org/ce/z/Q7mMC3

Summary:
Currently we have a conditional that turns the full build on by default
if it is a default target. This used to work fine when the GPU was the
only target that was ever present. However, we've recently changed to
allow building multiple of these at the same time. That means we should
have the ability to build overlay mode in the CPU mode and full build in
the GPU mode. This patch makes some simple adjustments to pass the
arguments per-triple. This slightly extends the existing `-DRUNTIMES_`
argument support to also transform any extra CMake inputs rather than
just the passed CMake variables.

That test is using std::toupper.

Code blocks and option points weren't rendered correctly

Summary:
This function was not actually supported, see
https://godbolt.org/z/MP1j5EeWc. Unsure why we only now begun seeing
failures related to it.

DecoderEmitter and CodeEmitterGen perform repeated linear walks over the
entire instruction list. This patch eliminates two more such walks.

The eliminated traversals visit every instruction merely to determine
whether the target has variable length encodings. For a target with
variable length encodings, the original any_of will terminate quickly.
But all targets other than M68k use fixed length encodings and thus
any_of must visit the entire instruction list.

Reverts llvm/llvm-project#84308

Failing bots, e.g.
https://lab.llvm.org/buildbot/#/builders/16/builds/62432

This moves a utility from `<tuple>` into an implementation detail header
and refactors the selection of the variant index type to use.

Avoid inspecting an operation that has been replaced.

This was detected by address sanitizer.

The Interpreter locks PTUs that originate from implicit runtime code and
initialization to prevent users from undoing them accidentally.

The previous implementation seemed hacky, because it required the reader
to be familiar with the internal workings of the PTU stack. The concept
itself is a pragmatic solution and not very surprising. This patch
introduces a function for it and adds a comment.

This pass was adding new function calls without adding the strictfp
attribute as required by the rules laid out in the langref. With this
change a make check has 4-5 fewer failing tests with the Verifier
changes in D146845.

LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

Test failures found with "https://reviews.llvm.org/D146845".

The wrong constructor of json::Value got called, making every tag an
array instead of a number.

llvm-reduce currently has a file `ReduceDPValues`, which really is
concerned with DbgRecords. Therefore, we rename the file and its
function accordingly.

This fixes tests that are going to be upstreamed in the near future.
Currently they are failing downstream in the Apple open source fork.

Failing tests
  Clang :: APINotes/retain-count-convention.m
  Clang :: APINotes/types.m
  Clang :: APINotes/versioned-multi.c
  Clang :: APINotes/versioned.m

Since 2e5af56b got merged, Clang now enables `LangOpts.APINotesModules`
when reading a precompiled module that was built with API Notes enabled.
This is correct. The logic in APINotesManager needs to be adjusted to
handle this.

rdar://123526142

Separated from #83251

The RelocationEntry's fields are poorly ordered when considering
padding. This reordering reduces the size from 56 bytes to 40 bytes (on
LP64).

Select POSIX 2008 standard to avoid including Darwin extensions.
Otherwise, Darwin's math.h header defines HUGE, which conflicts
with Flang's HUGE function.

This started happening after 4762c655 (#82443), that added the
"utility" include, which seems to include "math.h".

[X86] Assert that the supportedVectorShift* helpers are only called with generic shift opcodes. NFC.

RuntimeInterfaceBuilder wires up JITed expressions with the hardcoded
Interpreter runtime. It's used only for value printing right now, but it
is not limited to that. The default implementation focuses on an
evaluation process where the Interpreter has direct access to the memory
of JITed expressions (in-process execution or shared memory).

We need a different approach to support out-of-process evaluation or
variations of the runtime. It seems reasonable to expose a minimal
interface for it. The new RuntimeInterfaceBuilder is an abstract base
class in the public header. For that, the TypeVisitor had to become a
component (instead of inheriting from it). FindRuntimeInterface() was
adjusted to return an instance of the RuntimeInterfaceBuilder and it can
be overridden from derived classes.

This allows relying on VPBasicBlock::insert to make sure insertion is
well formed, i.e. by updating the recipe's parent as well as other
potential invariants in the future.

Move the narrow types assert from the ZERO_EXTEND/SIGN_EXTEND case in
fillUpExtensionSupport to getOrCreateExtendedOp so we check the other nodes
too.