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