This reworks the ArmSME dialect to use attributes for tile allocation.
This has a number of advantages and corrects some issues with the
previous approach:

* Tile allocation can now be done ASAP (i.e. immediately after
`-convert-vector-to-arm-sme`)
* SSA form for control flow is now supported (e.g.`scf.for` loops that
yield tiles)
* ArmSME ops can be converted to intrinsics very late (i.e. after
lowering to control flow)
 * Tests are simplified by removing constants and casts
* Avoids correctness issues with representing LLVM `immargs` as MLIR
values
- The tile ID on the SME intrinsics is an `immarg` (so is required to be
a compile-time constant), `immargs` should be mapped to MLIR attributes
(this is already the case for intrinsics in the LLVM dialect)
- Using MLIR values for `immargs` can lead to invalid LLVM IR being
generated (and passes such as -cse making incorrect optimizations)

As part of this patch we bid farewell to the following operations:

```mlir
arm_sme.get_tile_id : i32
arm_sme.cast_tile_to_vector : i32 to vector<[4]x[4]xi32>
arm_sme.cast_vector_to_tile : vector<[4]x[4]xi32> to i32
```

These are now replaced with:
```mlir
// Allocates a new tile with (indeterminate) state:
arm_sme.get_tile : vector<[4]x[4]xi32>
// A placeholder operation for lowering ArmSME ops to intrinsics:
arm_sme.materialize_ssa_tile : vector<[4]x[4]xi32>
```

The new tile allocation works by operations implementing the
`ArmSMETileOpInterface`. This interface says that an operation needs to
be assigned a tile ID, and may conditionally allocate a new SME tile.

Operations allocate a new tile by implementing...
```c++
std::optional<arm_sme::ArmSMETileType> getAllocatedTileType()
```
...and returning what type of tile the op allocates (ZAB, ZAH, etc).

Operations that don't allocate a tile return `std::nullopt` (which is
the default behaviour).

Currently the following ops are defined as allocating:
```mlir
arm_sme.get_tile
arm_sme.zero
arm_sme.tile_load
arm_sme.outerproduct // (if no accumulator is specified)
```

Allocating operations become the roots for the tile allocation pass,
which currently just (naively) assigns all transitive uses of a root
operation the same tile ID. However, this is enough to handle current
use cases.

Once tile IDs have been allocated subsequent rewrites can forward the
tile IDs to any newly created operations.

This introduces assembly support for the Checked Pointer Arithmetic
Extension (FEAT_CPA), annouced as part of the Armv9.5-A architecture
version.

The changes include:
* New subtarget feature for FEAT_CPA
* New scalar instruction for pointer arithmetic
  * ADDPT, SUBPT, MADDPT, and MSUBPT
* New SVE instructions for pointer arithmetic
  * ADDPT (vectors, predicated), ADDPT (vectors, unpredicated)
  * SUBPT (vectors, predicated), SUBPT (vectors, unpredicated)
  * MADPT and MLAPT
* New ID_AA64ISAR3_EL1 system register

Mode details about the extension can be found at:
* https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2023
* https://developer.arm.com/documentation/ddi0602/2023-09/



Co-authored-by: Rodolfo Wottrich <rodolfo.wottrich@arm.com>

GenericDomain -> SSEPackedInt

Found by #73654

Due to d0d2ee0e clang doesn't perform
qualified name lookup into the current instantiation when it has
dependent bases, because of that `getTypeName` call always returns null
for unknown specialization case. When there is a `typename` keyword,
`DependentNameType` is constructed instead of simply returning null.
This change attempts to do the same in case of `typename` absence.

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

This patch suggests to change two things. Firstly, it adds a source link
above the generated operations docs (above the `emitOpDoc` calls). This
link will point directly to the source TableGen file for the group of
operations. For example, for the current
[`amdgpu`](https://mlir.llvm.org/docs/Dialects/AMDGPU/) page, the link
will add a source link below the "Operation definition" heading pointing
to
[`mlir/include/mlir/Dialect/AMDGPU/IR/AMDGPU.td`](https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/AMDGPU/IR/AMDGPU.td).
The link is wrapped in a "op-definitions-source-link" class which could
allow for custom styling, but it also looks reasonable without custom
styling I think:

![afbeelding](https://github.com/llvm/llvm-project/assets/20724914/7c0e59b9-b14b-4f5d-a671-c87e857a7b03)

Secondly, this patch simplifies the header names such as "Operation
definition" and "Attribute definition" to "Operations" and "Attributes"
respectively. This is in line with manually defined subheadings on pages
such as the one for the
[`vector`](https://mlir.llvm.org/docs/Dialects/Vector/#operations)
dialect.

Add codegen support for extractelement when enable `lsx` or `lasx`
feature.

When a loop pass that does not preserve MSSA is run as part of a
loop-mssa pipeline, this is user error and we should not ask for
a bug report.

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

Out of curiosity, I ran [typos](https://github.com/crate-ci/typos)
against MLIR. It found two `CHECK:` typos (and many minor typos; which
I'm not gonna work on today).

Currently, the only mention of 0d vectors in the MLIR source code that I
could find was:

>     0D vectors are allowed by omitting the dimension: `vector<f32>`.

in
[`BuiltinTypes.td`](https://github.com/llvm/llvm-project/blob/437a48b2d9bfc6e38a0ca43f1cee48ceaf0fe249/mlir/include/mlir/IR/BuiltinTypes.td#L1046-L1047).

This patch adds a summary of
https://discourse.llvm.org/t/what-is-the-semantics-of-memref-0xf32-and-tensor-0xf32/3557
and https://discourse.llvm.org/t/should-we-have-0-d-vectors/3097/5.

KMOV is essential for copy between k-registers and GPRs.
R16-R31 was added into GPRs in #70958, so we extend KMOV for these new
registers first.

This patch
1.  Promotes KMOV instructions from VEX space to EVEX space
2.  Emits prefix {evex} for the EVEX variants
3. Prefers EVEX variant than VEX variant in ISEL and optimizations for
better RA

EVEX variants will be compressed to VEX variants by existing EVEX2VEX
pass if no EGPR is used.

RFC:
https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4
TAG: llvm-test-suite && CPU2017 can be built with feature egpr
successfully.

/llvm-project/clang/lib/Sema/MultiplexExternalSemaSource.cpp:317:2:
error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
};
 ^
1 error generated.

Despite CWG2497 not being resolved, it is reasonable to expect the
following code to compile (and which is supported by other compilers)

```cpp
  template<typename T> constexpr T f();
  constexpr int g() { return f<int>(); } // #1
  template<typename T> constexpr T f() { return 123; }
  int k[g()];
  // #2
```

To that end, we eagerly instantiate all referenced specializations of
constexpr functions when they are defined.

We maintain a map of (pattern, [instantiations]) independent of
`PendingInstantiations` to avoid having to iterate that list after each
function definition.

We should apply the same logic to constexpr variables, but I wanted to
keep the PR small.

Fixes #73232

Instead, create a mul24 with a 64 bit result and let ISel take care of
it.

This allows patterns to simply match mul24 even for 64-bit muls instead of having to match both mul/mulhi and a buildvector/bitconvert/etc.

The error message above has multiple lines on AIX, adding
`{{[[:space:]].*}}` to match multiple lines

Co-authored-by: Mark Danial <mark.danial@ibm.com>

7e425455 rejects unsupported mcmodel options, but normal/medium/extreme
should be supported models for LoongArch according to [gcc
document](https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html).

The mappings among `gcc`, `clang driver`, `clang cc1` and `LLVM (i.e.
llc --code-model=)` are:

|     gcc      |  clang driver |  clang cc1   |    LLVM    |
| -------------  | ------------------ | ----------------- | -------------- |
| normal    |      normal     |   small        |    small    |
| medium  |     medium     |   medium    |    medium |
| extreme  |     extreme     |  large         |     large     |

Link: https://reviews.llvm.org/D150522

Unlike mentioned in #73839, some OpenACC construct still need the cycle
branching check to be performed. This patch adds a list of construct
where the check is not needed (loop and combined construct) and add
tests to check where it is still needed.

Change fundersoring test with a more accurate regex to ensure the lack
of a trailing underscore, current TC is failing on AIX

Co-authored-by: Mark Danial <mark.danial@ibm.com>

[Clang][Lex] Fix parsing of nested requirement to prevent flowing off the end of token stream (#73691)

Currently when parsing a nested requirement we attempt to balance parens
if we have a parameter list. This will fail in some cases of ill-formed
code and keep going until we fall off the token stream and crash. This
fixes the hand parsing by using SkipUntil which will properly flag if we
don't find the expected tokens.

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

With these three intrinsics it's probable faster to check the number of
arguments first and then check the names. We can also handle ctlz and
cttz in the same block.

Just copy the `runOnFunction` method from `SafeStackLegacyPass` and
remove the workaround for computing analysis lazily, the analysis result
in new pass manager is computed lazily by default.

This commit explicitly adds a warm code section, .text.warm, when
-split-functions -split-strategy=cdsplit is used. This replaces the
previous approach of using .text.cold.0 as warm and .text.cold.1 as cold
in 3-way function splitting. NFC.

In this patch, we add support for checking a heterogeneous archive. We
also significantly improve the clang-offload-bundler documentation.