On 2/20/20 1:14 PM, GT wrote:
‐‐‐‐‐‐‐ 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.
Though I'm usually uncomfortable with kicking the can down the road on these
sorts of things, I can probably be convinced in this case. Tulio and I were
wondering why the libmvec interface doesn't make use of ifunc capability for
this sort of thing. Something to look into when more advanced implementations
are added later, I guess, and a valid reason to not lock ourselves into the
'c' ABI today.
Tulio, any concerns?
Bill
Bert.
