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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
