Multiple calls to `PointerType::getUnqual(C)`, and calls to
`Type::getPointerTo(AddrSpace=0)` on them all result in the same type.

Clean them up to re-use the same `PtrTy` variable within function
`createRegisterGlobalsFunction()`.

This adds riscv_bitmanip and riscv_crypto.h

This is based on the proposed spec here https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44

Tests that previously used builtins directly now use the intrinsics.

Reviewed By: wangpc

Differential Revision: https://reviews.llvm.org/D155647

Recommit of 0d2860b7 with extra test
cases fixed.

This makes the conditionals quite a bit simpler to understand, since it
avoids double negatives and makes sure we have <__availability>
included. For vendors which use availability macros, it also enforces
that they check when specific features are introduced and define the
macro for their platform appropriately.

Fix the 2 failed ompt tests on M1 device found on #63194.

```
libomp :: ompt/synchronization/masked.c
libomp :: ompt/synchronization/master.c
```

For the details of this fix, please check the origin discussion in
https://github.com/llvm/llvm-project/issues/63194#issuecomment-1710494689

Thanks @jprotze for the fix.

Hello!

This PR fixes #63871. Clang should no longer crash and instead emits an
error message.

Below is an example of the new error message:

```
~/dev/fork-llvm-project omp_dispatch_unimpl
❯ ./install/bin/clang -fopenmp  -c -emit-llvm -Xclang -disable-llvm-passes test.c
test.c:6:5: error: cannot compile this OpenMP dispatch directive yet
    6 |     #pragma omp dispatch
      |     ^~~~~~~~~~~~~~~~~~~~
1 error generated.
```

Specifying relocation fixup constants with name and type facilitates
readability and compile-time checks. The `FixupInfo<EdgeKind>` facade
organizes the information into entries per relocation type and provides
uniform access across Arm and Thumb relocations. Since it uses template
specializations, it doesn't limit potential entries. We cannot access
the entries dynamically though, because `EdgeKind` must be given as a
compile-time constant.

With this patch we populate a static lookup table on-demand and use it
for dynamic access in opcode-checks.

We want to use regular `stub_addr()` expressions in `jitlink-check` lines to test the generation of stubs in AArch32, but we don't want this to require a standardized GOT-based PLT implementation. In terms of performance and binary size it doesn't seem beneficial. And in terms of patching branch targets, we should be able to handle range-extension- and interworking-stubs without a lot of extra logic.

In order to allow such AArch32 stubs we add a separate path for `stub_addr()` expressions in `llvm-jitlink-elf`. The relocations in our stubs are not pointing to the GOT, but to the external symbol directly. Thus, we have to avoid access to the block of the edge target. Instead we only return the symbol name, which is enough to use `stub_addr()` expressions in tests.

The name of the AArch32 stubs section differs from the conventional `$__STUBS` on purpose. It allows to add a regular PLT/GOT implementation as an orthogonal feature in the future. In order to also allow decoding of stub target addresses in the future, we mention the stub flavor in the section name as well.

Add ad test case where `bl OUTLINED_FUNCTION_0` clobbers LR, which in
turn is used the later call to memcpy to return to the caller.

This is https://github.com/llvm/llvm-project/pull/69023 but with
cleanups.
Reduced complexity by avoiding CRTP and preprocessor defines in favor of
free functions

Original description by @unterumarmung:

---

This patch is part of a larger initiative aimed at fixing floating-point
`max` and `min` operations in MLIR:
https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671

.

There are two types of min/max operations for floating-point numbers:
`minf`/`maxf` and `minimumf`/`maximumf`. The code generation for these
operations should differ from that of other vector reduction kinds. This
difference arises because CL and GL operations for floating-point min
and max do not have the same semantics when handling NaNs. Therefore, we
must enforce the desired semantics with additional ops.

~~However, since the code generation for floating-point min/max
operations shares the same functionality as extracting values for the
vector, we have decided to refactor the existing code using the CRTP
pattern.~~ This change does not alter the actual behavior of the code
and is necessary for future fixes to the codegen for floating-point
min/max operations.

---------

Co-authored-by: Daniil Dudkin <unterumarmung@yandex.ru>

This reverts commit 12b0ab2c.

Currently failing on certain configurations due to a missing
constructor. Pulling out so that I can reproduce the issue and make sure
I fix it before resubmitting.

After the removal of the legacyPM version of simple loop unswitch, there
is no longer a need for the callback mechanism to handle PM specific
tasks. This patch removes the callbacks to help simplify the code now
that they're no longer needed.

This patch switches from using MCJIT to LLJIT as MCJIT is going to be
deprecated soon.

Fixes #41764.

Bail out of type conversion instead of crashing.

Fixes: https://github.com/llvm/llvm-project/issues/73289

The string pooling pass was incorrectly pooling global varables that
were part of llvm.used or llvm.compiler.used. This patch fixes the pass
to prevent that by checking each candidate to make sure that it is not
in either of those lists.

A miscompilation issue in the GISel pre-legalization
phase has been addressed with improved routines.

Fixes: https://github.com/llvm/llvm-project/issues/71440.

This flag indicates that every bit is known to be zero in at least one
of the inputs. This allows the Or to be treated as an Add since there is
no possibility of a carry from any bit.

If the flag is present and this property does not hold, the result is
poison.

This makes it easier to reverse the InstCombine transform that turns Add
into Or.

This is inspired by a comment here
https://github.com/llvm/llvm-project/pull/71955#discussion_r1391614578

Discourse thread
https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036

This fixes cases when SizeInBits is a multiple of the narrow size.

If SizeBits is equal to NarrowTy size, the first block would create an
illegal G_SEXT_INREG where the the extension size is equal to the type.
I tried to turn it into G_TRUNC+G_SEXT, but that just turned back into
G_SEXT_INREG causing an infinite loop. So punt to the splitting case.

In the for loop we should copy when the part ends on SizeInBits. In that
case there is no G_SEXT_INREG needed for partial. But we should note
that register in PartialExtensionReg for the first full part to use.

If the part starts on SizeInBits then we should do an AShr of
PartialExtensionReg.

We should only get to the G_SEXT_INREG case if the SizeInBits is in the
middle of the part.

Implements:
- P2871R3 Remove Deprecated Unicode Conversion Facets from C++26

Implements
- P2918R2 Runtime format strings II

The LinkageSpec case was omitted, and there is a declared CXCursor_Kind
for it. Adapt the testsuite drivers to print mangled names for
declarations with extern linkage. Also update the test baseline for the
recursive-cxx-member-calls.cpp test.

Co-authored-by: Matthieu Eyraud <eyraud@adacore.com>

Expr container, NFC.

Saves the memory and may improve compile time.

As per the RFC:
[https://discourse.llvm.org/t/rfc-flang-new-directory-for-adding-end-to-end-tests-for-lowering-to-llvm-ir-in-flang/74872/11](https://discourse.llvm.org/t/rfc-flang-new-directory-for-adding-end-to-end-tests-for-lowering-to-llvm-ir-in-flang/74872/11),
this patch adds a new Integration test directory for OpenMP-
`flang/test/Integration/OpenMP` and moves the existing OpenMP
integration tests from `flang/test/Driver/OpenMP` to this directory.

**This directory can be used to add Integration tests involving multiple
stages of the compiler (for eg. from Fortran to LLVM IR). It should not
contain executable tests. We should only add tests here sparingly and
only if there is no other way to test. Repeat this message in each test
that is added to this directory and sub-directories.**

This will be used to support conditional compilation based on compiler
version.
We adopt the same convention as
[libc++](https://github.com/llvm/llvm-project/blob/main/libcxx/include/__config)
- thx @legrosbuffle for the suggestion!
Usage:
```
#if defined(LIBC_COMPILER_CLANG_VER)
#  if LIBC_COMPILER_CLANG_VER < 1500
#    warning "Libc only supports Clang 15 and later"
#  endif
#elif defined(LIBC_COMPILER_GCC_VER)
#  if LIBC_COMPILER_GCC_VER < 1500
#    warning "Libc only supports GCC 15 and later"
#  endif
#elif defined(LIBC_COMPILER_MSC_VER)
#  if LIBC_COMPILER_MSC_VER < 1930
#    warning "Libc only supports Visual Studio 2022 RTW (17.0) and later"
#  endif
#endif
```

Fixes [#68035](https://github.com/llvm/llvm-project/issues/68035), where
an inconsistency in the order of "Process launched" and "Process
stopped" messages occurs during `process launch`.

The fix involves adjusting the message output sequence in
`CommandObjectProcessLaunch::DoExecute` within
`source/Commands/CommandObjectProcess.cpp`. This ensures "Process
launched" consistently precedes "Process stopped" when executing
commands with the '-o' flag, i.e., non-interactive mode.

Upon implementing this change, two tests failed:
`lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test` and
`lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test`. These failures
were expected as they relied on the previous, now-corrected message
order. Updating these tests to align with the new message sequence is
part of this PR's scope.

```
llvm-project/clang/include/clang/AST/OpenMPClause.h:7762:14: warning: parameter 'Modifier' not found in the function declaration [-Wdocumentation]
  /// \param Modifier The modifier applied to 'order' clause.
             ^~~~~~~~
llvm-project/clang/include/clang/AST/OpenMPClause.h:7762:14: note: did you mean 'M'?
  /// \param Modifier The modifier applied to 'order' clause.
```

This patch adds support for CloneBasicBlock duplicating the DPValues
attached to instructions, and adds facilities to remap them into their new
context. The plumbing to achieve this is fairly straightforwards and
mechanical.

I've also added illustrative uses to LoopUnrollRuntime, SimpleLoopUnswitch
and SimplifyCFG. The former only updates for the epilogue right now so I've
added CHECK lines just for the end of an unrolled loop (further updates
coming later). SimpleLoopUnswitch had no debug-info tests so I've added a
new one. The two modified parts of SimplifyCFG are covered by the two
modified SimplifyCFG tests.

These are scenarios where we have to do extra cloning for copying of
DPValues because they're no longer instructions, and remap them too.

There's good justification for having a function specifying "I need there to be
a marker here, so return the marker there or create a new one". This was going
to come later in the series, but it's starting to become necessary much eariler
alas.

Make use of it in spliceDebugInfo, where we can occasionally splice DPValues
onto the end() iterator of a block while it's been edited.

Floating point properties are a combination of target OS, target
architecture and compiler support.
 - Adding target OS detection,
 - Moving floating point type detection to its own file.

This is in preparation of adding support for `_Float16` which requires
testing compiler **version** and target architecture.

Avoid some spurious changes in a future patch.

There have been some minor but pervasive changes to the generated
CHECK lines, so regenerate all of them, to minimize future diffs.

The new libcxx workflow are run and failing in non llvm repo.
Skip it similar to other workflow.

Manually add clobbers for various register combinations to tests. This
highlights incorrectly performing shrink-wrapping, with
StoreSwiftAsyncContext expansion clobbering a live register.

If GOTSym is not defined, we cannot call `GOTSym.getBlock()`. It failed with:
```
Assertion failed: (Base->isDefined() && "Not a defined symbol"), function getBlock, file JITLink.h, line 554.
```

Explicitly include some headers or forward-declare types, in
preparation for removing an include that pulls in many transitive
headers.

Import of a function with `auto` return type that is expanded to a
`SubstTemplateTypeParmType` could fail if the function itself is the
template specialization where the parameter was replaced.