It's possible (though inadvisable) to use LDR and refer to labels in
different
sections. In the Arm state, the assembler resolves the LDR instruction
without
emitting a relocation. That's incorrect because the assembler cannot
make any
assumptions about the relative position of the sections and the compiler
output
is therefore wrong.

This patch ensures relocations are generated for all `LDR <Rt...>,
label`
instructions in the Arm state (little endian). This is not necessary
when the
label is in the same section but the relocation is now generated
regardless.
Instructions that now generate relocations have been removed from the
pcrel-global.s test.

Fortunately, LLD already implements the generated relocations and can
fix LDR
instructions when the symbol is in a different section, or report an
error if
the offset is too large for the immediate field in the particular LDR's
encoding.

The patch to address this problem for big endian targets will follow, as
well
as a fix for ADR that exhibits a similar behavior.

This patch refactors tests for:

   * vector.contract -> vector.outerproduct

transformations for matvec operations (b += Ax). Specifically, relevant
tests from the following 2 files:

   * vector-contract-matvec-transforms.mlir
   * vector-contract-to-outerproduct-transforms.mlir

are combined into one:

  * vector-contract-to-outerproduct-matvec-transforms.mlir

All original tests are preserved and no new tests are added.

This is a part of a larger effort to add cases with scalable vectors
to tests for the Vector dialect. I am refactoring these test as a
preparation for follow-up patches.

Implements #72834.

The `getGenericEdgeKindName()` function returned "<Unrecognized edge kind>" for all our relocations.
We must use `aarch32::getEdgeKindName()` instead.

PR for: https://discourse.llvm.org/t/add-check-mlir-python-to-the-mlir-pre-commit-tests/74041

It’s easy to forget about the Python bindings and not build/test them
locally. It’s also easy to change something that’ll break the python
binding tests and not find out till after you’ve committed your change.

These tests seem to run quickly and don’t require much extra setup, so
let's add them to the general MLIR pre-merge tests.

-0.0 acts as the identity element for fadd. This doesn't try to add 0.0
too, which would require nsz fast math flags.

Some operations defined their syntax both in the documentation and via
`assemblyFormat`. This leads to two `Syntax:` subheadings in the
documentation, see for example the documentation for
[`arith.maximumf`](https://mlir.llvm.org/docs/Dialects/ArithOps/#arithmaximumf-arithmaximumfop).
Since the `assemblyFormat` is used to generate the actual parsers and
printer implementations, this PR suggest to remove the manual syntax
descriptions.

We can fold the G_FRAME_INDEX into a load/store address.

This test case depends on the stderr output of a `nullptr` being
"(null)". However, it is empty string on AIX.
This PR is to initialize the `sourceFileName_` to be a specific string
to avoid that.

Work towards to the TODO item of removing method `Type::getPointerTo`
(as noted in llvm/include/llvm/IR/Type.h).

Opaque ptr cleanup effort (NFC).

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.