On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote:
> > 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.
Whether simd attribute or declare simd emits by default just 'b' or both 'b'
and 'c' or whatever other set is part of the ABI, so if/when that will
change, it will be an ABI break.
>From this POV, handling faster (higher ISA), but same ABI, power9 optimized
code through ifuncs rather than a separate set of entrypoints might be
better.
It is true that it won't affect that way non-glibc code which won't use
ifunc manually like libmvec would, on the other side, OpenMP 5.0 has now
ways to handle such specialization through #pragma omp declare variant.
Jakub
