So that we can benefit from some instcombine optimizations.

This PR contains two commits: the first is for adding tests and the
second is for the optimization.

This restores commit c7fdd8c1.
Previously reverted in f010b1be.

LLVM function calls carry convergence control tokens as operand bundles, where
the tokens themselves are produced by convergence control intrinsics. This patch
implements convergence control tokens in MIR as follows:

1. Introduce target-independent ISD opcodes and MIR opcodes for convergence
   control intrinsics.
2. Model token values as untyped virtual registers in MIR.

The change also introduces an additional ISD opcode CONVERGENCECTRL_GLUE and a
corresponding machine opcode with the same spelling. This glues the convergence
control token to SDNodes that represent calls to intrinsics. The glued token is
later translated to an implicit argument in the MIR.

The lowering of calls to user-defined functions is target-specific. On AMDGPU,
the convergence control operand bundle at a non-intrinsic call is translated to
an explicit argument to the SI_CALL_ISEL instruction. Post-selection adjustment
converts this explicit argument to an implicit argument on the SI_CALL
instruction.

In case of loads/stores from an immediate address, avoid rematerializing
the constant for every block and allow consthoist to hoist it to the
entry block.

There were a number of issues that needed to be addressed:
- i64 to bf16 did not correctly round
- strict rounding needed to yield a chain
- fastisel did not have logic to bail on bf16

The rest of the code pretty much assumed this anyway.

Show argument names in signature help when calling a function pointer
struct field.

When converting complex.atan2 op to standard, we need to keep the fast
math flag given to the op.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

toHalfOpenFileRange() already handles translating macro locations to
file locations, and it can provide a better result by knowing about both
ends of the range.

Fixes https://github.com/clangd/clangd/issues/1941

Summary:
This patch fixes some issues with building the GPU target manually
without the runtimes bootstrapping build. This fixes the install
directory and sets the default namespace to something more sensible if
not set. Also I got rid of the check on `-mcpu=native`. it was a neat
trick, but CMake in its INFINITE wisdom does not allow you to set link
flags on the compiler flag check. So I just went with the old tool
usage.

Summary:
We already had a special CUDA default that better tracked the state as
of modern CUDA installations. Recently this was bumped up to `sm_52`,
but there was a location that wasn't respecting this. Fix that.

When reference-types feature is enabled, forcing mem2reg unconditionally
even in `-O0` has some problems described in #81575. This uses
RefTypeMem2Local pass added in #81965 instead. This also removes
`IsForced` parameter added in

https://github.com/llvm/llvm-project/commit/890146b19206827bc48ee1ae1dc1534ff2ff18d7
given that we don't need it anymore.

This may still hurt debug info related to reference type variables a
little during the backend transformation given that they are not stored
in memory anymore, but reference type variables are presumably rare and
it would be still a lot less damage than forcing mem2reg on the whole
program. Also this fixes the EH problem described in #81575.

Fixes #81575.

This fixes buildbot failures:
https://lab.llvm.org/buildbot/#/builders/57/builds/33206

If AMD GPUs don't exist when building libomptarget, the early return causes skipping the plugin installation.

Reverts llvm/llvm-project#83259

This broke an integration test on Windows

Clang and some middle-end optimizations may need these helper
functions.

This can reduce some duplications.

llvm-project/lldb/source/Core/Debugger.cpp:107:14:
error: no type named 'DefaultThreadPoolThreadPool' in namespace 'llvm'
static llvm::DefaultThreadPoolThreadPool *g_thread_pool = nullptr;
       ~~~~~~^
1 error generated.

A few notes:
* pr34538.ll has bitrotten.  The original test printed the analysis after transforms in some cases, but this appears to been lost during migration to new pass manager.  Remove the now redundant pass invocations and simplify the test setup.

relate:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645016.html

The base class llvm::ThreadPoolInterface will be renamed
llvm::ThreadPool in a subsequent commit.

This is a breaking change: clients who use to create a ThreadPool must
now create a DefaultThreadPool instead.

In advance of a change which needs to update these.  This batch was the
"easy" ones, I'll be landing the harder set a few a time for easier
review.

Since `llvm.compressstore` and `llvm.expandload` do require memory
access, it's essential for some target to check if alignment is good to
be able to lower them to target-specific instructions

Try to fix https://github.com/llvm/llvm-project/issues/83845


When `std::forward` is invoked in a function, make sure it uses correct
parameter by checking if the bounded `var` equals the parameter.

Co-authored-by: huqizhi <836744285@qq.com>

If the "march" has some extension with version that is not supported, it
returns the error message like: "error: invalid arch name 'some_arch',
unsupported version number 2.0 for extension 'some_arch'", which is not
precise enough, it should return the message that only tells users "the
extension is not supported".

Currently using the command `clang -cc1 -triple riscv64` to compile the
code below:
```
#include <riscv_vector.h>
void foo() {
  vfloat64m1_t f64m1;
}
```
would get the error message "RISC-V type 'vfloat64m1_t' ... requires the
'zve64x' extension"
which is supposed to be "RISC-V type 'vfloat64m1_t' ... requires the
'zve64d' extension".

These are really the same as the f16 (and i16) instructions, but we need
them for any type that can occur.

Reverts llvm/llvm-project#83948

This broke the ASan buildbot:
https://lab.llvm.org/buildbot/#/builders/168/builds/19054/steps/10/logs/stdio

API clients can now set a MachO::HeaderOptions::BuildVersionOpts field to have
MachOPlatform add an LC_BUILD_VERSION load command to the Mach header for each
JITDylib.

No testcase yet. In the future we'll try to add a MachO parser to the ORC
runtime and extra test options to llvm-jitlink for this.

This commit also incidentally fixes a bug in the MachOBuilder class that lead to
a delegation cycle.