[clang] [llvm] [SystemZ] Add i128 support for z/OS XPLINK64 ABI (PR #223026)

[Ulrich Weigand via cfe-commits]

uweigand wrote:

> **Clang:** `i128` is gated behind the vector facility (`arch11`/z13) via `hasInt128Type()`. A new driver diagnostic (`err_drv_incompatible_arch`) is emitted when `-mvx` is used with hard-float ABI on a pre-arch11 target. `Triple` is threaded through `getSystemZTargetFeatures()` to support this check.

This doesn't make sense.  The point of the `-mvx` option is to *enable* use of the vector facility, no matter which `-march` level is selected.   If you want to make use of the `i128` type dependent on the vector facility, it should simply check for the facility.

That said, it seems unfortunate to make the type dependent on the facility.  Not even *vector types* themselves are dependent on the facility - they're emulated if the facility is not available.  This means there is already a variant ABI for vector types if the vector facility is not available.  It would seem less surprising to include `i128` in that variant ABI.
 
> **Backend:** `CC_XPLINK_Int128` maps `i128` to `v16i8` for register allocation. `convertLocVTToValVT`/`convertValVTToLocVT` are extended to handle the `i128`↔`v16i8` bitcast. The `i128` return-via-stack path is guarded behind `isTargetLinux()` so z/OS returns in a vector register instead.

Why is all this necessary?   The current code base accepts `i128` as legal type in vector registers, so there should be no need for this conversion.

> Add `i128` support for the z/OS XPLINK64 calling convention. Arguments and return values of type `i128` are passed in vector registers (VR24–VR31) as `v16i8`.

It seems to be that simply adding `i128` here:
```
  // Other vector arguments are passed in 8-byte-aligned 16-byte stack slots.
  CCIfSubtarget<"hasVector()",
    CCIfType<[v16i8, v8i16, v4i32, v2i64, v8f16, v4f32, v2f64],
             CCAssignToStack<16, 8>>>,
```
(and likewise for the return calling convention) should be enough to implement the desired ABI.


https://github.com/llvm/llvm-project/pull/223026