This commit allows a final progress report upon the destruction of the
`Progress` object to happen at all times as opposed to when the progress
was not completed.

Both active C++ proposals (P1144 and P2786) agree that
`is_trivially_relocatable_v<int&>` and
`is_trivially_relocatable_v<int()>` should be false, not true. Only
complete object types can be trivially relocatable.

Fixes #67498

These tests use an old way to test code in constexpr context. This
changes the code to the idomatic libc++ method.

This is a preparation for #73162.

Side changes
- Updated formatting
- Made some helper functions constexpr
- Some naming improvements

Similar to #73677, there is no benefit from keeping MemoryManager
seperate; it's tied into the current design. Except the move I also
replaced the getenv call with our Env handling.

Some of the files in the docs/ directory are from 2019 and haven't been
updated since. This patch updates implementation_standard.rst,
source_tree_layout.rst, and has some minor fixes for strings.rst. It
also marks the most severely out of date files with a warning. These
files will be updated in a later patch.

This was causing an assert on invalid in the modified test case.

This change makes x64 enablement case explicit and
adds an else case for 32bit which fixes a regression
on Windows i386 asan builds introduced
by https://github.com/llvm/llvm-project/pull/66973.

The overhead of a library and 4 files seems high without benefit. This
simply tries to consolidate our structure.

We can use inline constants with packed 16-bit operands, but these
should use op_sel. Currently splat of inlinable constants is considered
legal, which is not really true if we fail to fold it with op_sel and
drop the high half. It may be legal as a literal but not as inline
constant, but then usual literal checks must be performed.

This patch makes these splat literals illegal but adds additional logic
to the operand folding to keep current folds. This logic is somewhat
heavy though.

This has fixed constant bus violation in the fdot2 test.

Clarify how the addend is used in _HI relocation types like
R_AMDGPU_ABS32_HI based on the current behaviour of the Mesa and AMDPAL
ELF loaders.

This affects Mesa and AMDPAL because they use REL relocation records, so
the addend for these types is the 32-bit literal value from the
instruction being relocated. AMDHSA is not affected because it uses RELA
relocation records which have a 64-bit addend.

`A program may not branch into or out of a compute construct.` This
restriction is also true for combined constructs. This patch enforce
this rule.

This implements assembly support for the Debug/PMU extensions introduced
as part of the Armv9.5-A architecture version.
The changes include:
* New ID_AA64DFR2_EL1 ID system register
* New MDSTEPOP_EL1 and SPMZR_EL0 system registers

Mode details about these extensions 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: Oliver Stannard <oliver.stannard@arm.com>

Also rename the fixture class since these tests are not ELF-specific.

In https://github.com/llvm/llvm-project/pull/71780 we started emitting
definitions for all static data-members with constant initialisers, even
if they were constants (i.e., didn't have a location). We also dropped
the DW_AT_const_value from the declaration to [help resolve
inconsistencies during type merging in the
DWARFParallelLinker](https://github.com/llvm/llvm-project/pull/68721).
However, for static data members that do have locations, we wouldn't
emit a DW_AT_const_value on it, assuming that the consumer knows how to
read the value using the location. This broke some consumers that really
wanted to find a DW_AT_const_value. Ultimately we want to attach a
DW_AT_const_value to definitions that have a location too. But to fix
consumers broken by said change, this patch adds the constant back onto
the declaration. This is what we used to do prior to
https://github.com/llvm/llvm-project/pull/71780

If we have a high LMUL build_vector and a known exact VLEN, we can
decompose the build_vector into one build_vector per register in the
register group. Doing so requires exact knowledge of which elements
correspond to each register in the register group, and thus an exact
VLEN must be known.

Since we no longer have operations which are linear (or worse) in LMUL,
this also allows us to lower all build_vectors without resorting to
going through the stack.

...to model the results of alloca() and _alloca() calls. Previously it
acted as if these functions were returning memory from the heap, which
led to alpha.security.ArrayBoundV2 producing incorrect messages.

This was suggested in another related review, so backporting it to the
existing code as well.

No need to store optional boolean in the map, enough to store boolean
directly. Also, we can do preliminary check for instruction and if they
are not simple, mark as aliased without storing this result in the map.

This is a direct follow-up of #73348. The matvec trait that's used for
`@matvec_m_mk_k` was incorrectly updated from:

```
#redpar_vecmattrans_accesses = [
  affine_map<(m, k) -> (m)>,
  affine_map<(m, k) -> (m, k)>,
  affine_map<(m, k) -> (k)>
]
  indexing_maps = #redpar_vecmattrans_accesses,
  iterator_types = ["reduction", "parallel"]
}
```

to:

```
#matvec_accesses_4 = [
  affine_map<(m, k) -> (k)>,
  affine_map<(m, k) -> (k, m)>,
  affine_map<(m, k) -> (m)>
]
  indexing_maps = #matvec_accesses_4,
  iterator_types = ["parallel", "reduction"]
}
```

Note that these traits describe identical matvec operation, hence the
`CHECK` lines are identical for both.

Also, `#redpar_vecmattrans_trait` is identical to `#matvec_trait_8`
that's already present in:

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

For this reason:
* `@matvec_m_mk_k` is moved near other tests that already use
`#matvec_trait_8`,
  * `#redpar_vecmattrans_trait` is replaced `#matvec_trait_8`.

This is a part of a larger effort to add cases with scalable vectors to
tests for the Vector dialect. I am refactoring these tests so that it's
easier to identify what cases are tested and where to add tests for
scalable vectors.

Implements #72834.

Parameters marked as uniform take a scalar value, assuming the value is
invariant in the scalar loop.

Just follow along with the reassociate pragma. This allows locally
setting the arcp fast math flag. Previously you could only access this
through the global -freciprocal-math.

Fixes #64798

This was overriding the Predicate list computed by PredicateControl.
There are other places that seem to also be setting confusing overrides
of computed predicate lists.

Allow foldImmediate to create instructions like:

  v_fmaak_f32 v0, s0, v0, 0x42000000

This instruction has two "scalar values": s0 and 0x42000000. On GFX10+
this is allowed. This fold was originally implemented before the
compiler supported GFX10, when all ASICs were limited to one scalar
value.

While 0b80288e allowed more efficient lowering for 16xi8 loads, its
test case was closer to an "integration" one. Add a much simpler unit
test case that exercises it.

In preparation for handling non-assume context-sensitive facts.