‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 19, 2020 12:33 PM, Bill Schmidt <wschm...@linux.ibm.com> wrote:
> > The reason 'c' was added to the ABI is this mailing list discussion: > > https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html > > As long as 'b' specifies that the VSX functionality is that specified in > > ISA v2.07, > > I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio? > > No, I don't think that's the right call. We want to leverage ISA 3.0 > instructionsin vector implementations when they are available, so we > need the 'c' ABI for that purpose. In future we are likely to add a > 'd' ABI for a future processor if it adds more vector capability. So > emitting both and letting the vectorized callers choose, as Jakub > suggests, seems like the right way to go. This is true even if the > current implementations are identical (i.e., don't exploit any ISA > 3.0 instructions). > Because of the issue at https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01171.html, I am coming back to whether or not to include VSX extensions for ISA 3.0 in the Vector Function ABI Specification. If we retain 'c' in the ABI Spec., then GCC will expect libmvec functions such as _ZGVcN2v_sin. The changes made to GLIBC for POWER libmvec don't have these functions with <isa> == 'c'. Only those with <isa> == 'b' have been implemented. So we have to do either of: 1. Create all those 'c' variants in GLIBC libmvec, even though they will be identical to the existing 'b' versions. 2. Remove all references to 'c' in the ABI Specification, and leave GCC expecting to find only 'b' variants in libmvec. If/when it becomes necessary to have 'c' variants of functions, then a new version of the Vector Function ABI document will be created. And GLIBC and GCC modifications to comply with that new ABI will be made then. Bert.