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

[Ulrich Weigand via cfe-commits]

uweigand wrote:

> On z/OS, unlike Linux ELF, there is no vector emulation for pre-z13 targets — vector types are not legal types when hasVector() is false. Since i128 uses VR128BitRegClass (same as vectors), it similarly requires the vector facility.

Sure, at the back-end level the LLVM IR vector types are marked as not legal.  But this only means that the middle-end emulates those types in terms of other types - front ends can still use them.  This applies both to the clang front-end (the C/C++ language extensions to support vector types are available always), as well as LLVM IR generated by other front ends.

In fact, I do not see any code in the current code base that would lead to any difference between Linux and z/OS targets here.   I guess you *could* disable the Z specific vector extension (`vector unsigned int` etc.), but that isn't currently being done.   And even then, there's still the generic vector extension (`__attribute__((vector_size(...)))`, that would still allow generating vector types.  And of course other front-ends may always generate any LLVM IR vector type - every back-end is always supposed to handle any of those, whether they match an ISA vector register size or not.

The same of course applies to i128 - this is always handled *some* way.  If the type is not legal in the back-end, the middle-end will choose how to emulate it (usually in terms of a pair of i64).   Note that this will in fact anyway create -at least implicitly- an ABI.   It would be better to make some explicit (reasonable) choice for this ABI - and once you have a well-defined back-end ABI for `i128`, there is no reason to not support `__int128_t` in the front end.


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