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.

We were setting based on whether the FP value is positive/negative, but
we really want to know whether the resulting integer will be treated as
a signed or unsigned value. Since we use SINT_TO_FP to convert the
integer to FP, we should always used signed here.

Without this we convert +2147483648.0 to an integer 0x80000000 and
convert it using sint_to_fp which produces -2147483648.0.

Fixes #84025.

Read .parainstruction section and mark call instructions with ParaSite
annotations.

Clang sets the nonlazybind attribute for certain ObjC features. The
AArch64 SelectionDAG implementation for non-intrinsic calls
(46e36f09) is behind a cl option.

GCC implements -fno-plt for a few ELF targets. In Clang, -fno-plt also
sets the nonlazybind attribute. For SelectionDAG, make the cl option not
affect ELF so that non-intrinsic calls to a dso_preemptable function use
GOT. Adjust AArch64TargetLowering::LowerCall to handle intrinsic calls.

For FastISel, change `fastLowerCall` to bail out when a call is due to
-fno-plt.

For GlobalISel, handle non-intrinsic calls in CallLowering::lowerCall
and intrinsic calls in AArch64CallLowering::lowerCall (where the
target-independent CallLowering::lowerCall is not called).
The GlobalISel test in `call-rv-marker.ll` is therefore updated.

Note: the current -fno-plt -fpic implementation does not use GOT for a
preemptable function.

Link: #78275

Pull Request: https://github.com/llvm/llvm-project/pull/78890

For `LDBL_MANT_DIG == 113` targets the FortranFloat128Math library
is just an interface library that provides sources and compilation
options to be used for building FortranRuntime - there are not extra
dependencies on other libraries, so it can be a part of FortranRuntime,
which helps to avoid extra linking steps in the compiler driver.
Targets with __float128 support in libc will also use this path.
Other targets, where the math support comes from
FLANG_RUNTIME_F128_MATH_LIB,
FortranFloat128Math is built as a standalone static library,
and the compiler driver needs to conduct the linking.

Flang APIs for COMPLEX(16) are just thin C wrappers around
the C math functions. Flang uses C _Complex ABI for passing/returning
COMPLEX values, so the runtime is aligned to this.

This PR implements the frontend for llvm#70100
This PR is part 1 of 2.
Part 2 requires an intrinsic to instructions lowering.


- `Builtins.td` - add an `rcp` builtin
- `CGBuiltin.cpp` - add the builtin to intrinsic lowering
-  `hlsl_intrinsics.h` - add the `rcp`  api
- `SemaChecking.cpp` - reuse frac's sema checks
- `IntrinsicsDirectX.td` - add the llvm intrinsic

The lowering is not distinquishing -2147483648.0 and 2147483648.0.

The architecture of SPIRVEmitIntrinsics is build in such way that every
private method is called by one main function runOnFunction which then
calls private methods. Private member IRB is allocated in runOnFunction
method but it's not freed. Due to that every time when IR function
contains intrinsics to emit, runOnFunction is entered and memory is
leaked on exit. It's especially true when there are two or more IR
functions to emit. IRB is set to nullptr during construction of object
and it's left without pointing resource until runOnFunction is entered.
This also create possibility of simple mistake when private method is
called but there is no resource pointed. Change requires passing
IRBuilder by reference to private methods. The visit* functions create
it's own IRBuilder thus IRB is eliminated from class scope. In addition
there is a small performance improvement because IRBuilder is not
allocated by heap.

The watchOS and tvOS sanitizers do not compile with publicly-available
SDKs, failing on calls such as fork() and posix_spawn(). Updating the
darwin_test_archs test program to include a call to fork() allows cmake
to exclude those platforms when compiling runtimes. This allows public
builds to enable watchOS/tvOS and compile builtins but not sanitizers.

The ppa2list section isn't really part of the ppa2 section. The ppa2list
section contains the offset to the ppa2, and must be created with a
special section name (specifically, C_@@QPPA2). The binder searches for
a section with this name, then uses this value to locate the ppa2.

In GOFF terms, these are entirely separate sections; the PPA2 section
isn't even really a section but rather belongs to the code section. On
the other hand, the ppa2list section is a section in its own right and
resides in a separate TXT record.

We always provide the std:: exception types, even when exceptions are
disabled. This is a bit counter-intuitive, but these exception types are
just normal types at the end of the day so we made the decision to
always provide their definition. Failure to re-export these types would
cause libc++ to fail to link on Apple platforms when exceptions are
disabled.

Continuing the efforts started in #83357

This does not apply well to LLVM which intentionally rely on forward
declarations. Also depending on the config flags passed to CMake the
result can be different.

This reverts commit a730ed7c to fix
compile time issue.