This patch adds support for the next-generation arch15
CPU architecture to the SystemZ backend.

This includes:
- Basic support for the new processor and its features.
- Detection of arch15 as host processor.
- Assembler/disassembler support for new instructions.
- Exploitation of new instructions for code generation.
- New vector (signed|unsigned|bool) __int128 data types.
- New LLVM intrinsics for certain new instructions.
- Support for low-level builtins mapped to new LLVM intrinsics.
- New high-level intrinsics in vecintrin.h.
- Indicate support by defining  __VEC__ == 10305.

Note: No currently available Z system supports the arch15
architecture.  Once new systems become available, the
official system name will be added as supported -march name.

Use SExt instead of ZExt in XForms which produce a signed value. This is
only to make it clear that the XForm handles a signed value.

A follow-up to PR #117181: SIMM32 must use getSignedTargetConstant(),
too.

This will avoid assertion failures once we disable implicit truncation
in getConstant().

Inside adjustSubwordCmp() I ended up suppressing the issue with an
explicit cast, because this code deals with a mix of unsigned and signed
immediates.

On processors supporting vector registers and SIMD instructions, enable
i128 as legal type in VRs. This allows many operations to be implemented
via native instructions directly in VRs (including add, subtract,
logical operations and shifts). For a few other operations (e.g.
multiply and divide, as well as atomic operations), we need to move the
i128 value back to a GPR pair to use the corresponding instruction
there. Overall, this is still beneficial.

The patch includes the following LLVM changes:
- Enable i128 as legal type
- Set up legal operations (in SystemZInstrVector.td)
- Custom expansion for i128 add/subtract with carry
- Custom expansion for i128 comparisons and selects
- Support for moving i128 to/from GPR pairs when required
- Handle 128-bit integer constant values everywhere
- Use i128 as intrinsic operand type where appropriate
- Updated and new test cases

In addition, clang builtins are updated to reflect the intrinsic operand
type changes (which also improves compatibility with GCC).

Currently mentioning any symbols in immediate asm operands is not
supported, for example:

    error: invalid operand for instruction
    lghi %r4,foo_end-foo

The immediate problem is that is*Imm() and print*Operand() functions do
not accept MCExprs, but simply relaxing these checks is not enough:
after symbol addresses are computed, range checks need to run against
resolved values.

Add a number of SystemZ::FixupKind members for each kind of immediate
value and process them in SystemZMCAsmBackend::applyFixup(). Only
perform the range checks, do not change anything.

Adjust the tests: move previously failing cases like the one shown
above out of insn-bad.s.

Reviewed By: uweigand

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

Prepare for removing the MemOpsEmitted workaround for symbolic
displacements by letting TableGen know about the offsets of the
displacement sub-operands within the instruction.

There are alternative ways to do this that were tried and rejected:

- Creating encoders and decoders for each possible displacement offset.
  This is too repetitive.

- Use VarLenCodeEmitter [1]. The resulting diff is quite large.

Instead, use the named sub-operand support introduced by commit
a538d1f13a13 ("[TableGen][CodeEmitterGen] Allow local names for
sub-operands in a operand list.").

Describe instruction encodings in terms of sub-operands instead of
operands (e.g. B, D, L vs BDL) - this also better matches the pictures
from the Principles of Operation. Decompose operands into sub-operands
using the new (bdaddr12only $B1, $D1):$BD1 syntax. Replace the
encoders and the decoders of the operands with these of the
sub-operands.

Since DecodeADDR64BitRegisterClass() is now used for bases and indices,
change it to return NoRegister when decoding 0. This also changes the
disassembly of some instructions, e.g., br %r0 becomes br 0. Since this
better captures the instruction semantics, namely, that the value of
%r0 is not used, keep this change and update the tests.

[1] https://m680x0.github.io/blog/2022/02/varlen-encoder.html

Reviewed By: uweigand

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

They are no longer used, which leads to the -Wunused-function warning.

Reviewed By: uweigand

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

For all RotateSelect* instructions, PoP says:

    Bits 0-1 of the I5 field (bits 32-33 of the instruction) are
    ignored.

LLVM, however, completely prohibits using them, e.g.:

    error: invalid operand for instruction
    asm("rxsbg %[r1],%[r2],177,43,228\n"

Lift this unnecessary restriction.

Reviewed By: uweigand

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