This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] Aarch64: Add simd exp/expf functions


On 23/05/2019 11:53, Szabolcs Nagy wrote:
> (1) it is not obvious that we can enable libmvec in glibc
> without a toolchain that follows the new ELF abi.

i was thinking about this and i believe we can add
libmvec abi without toolchain support (e.g. dummy
asm implementation that falls back to scalar code).

testing the code requires toolchain support, but i
think that can be conditional.

>> There was a question of whether building libmvec should be optional or not,
>> I don't have a strong opinion on that but would be interested in what others
>> think.  I could change this to require aarch64_vector_pcs attribute support
>> in all cases and always build libmvec if that is what we want.

i would add libmvec unconditionally with dummy
implementations and then the abi is in place for
later backports of algorithms.

> (2) we need to decide between 'experimental abi' or dummy libmvec
> or increasing the minimum toolchain requirement.
> 
> (3a) in case of 'experimental abi' there has to be some
> description about what users can expect and how to opt out
> from using libmvec to build portable binaries.
> 
> (3b) in case of dummy libmvec the glibc mechanism to provide
> it and test it should be figured out.

i think dummy libmvec may work for now.

unfortunately in math.h omp declare simd would imply
the availability of both advsimd and sve functions.
there will be a way to say "only advsimd version is
available", but gcc does not support that yet.
so we can

(1) add omp declare simd to math.h and add dummy sve
    symbols too. (however sve calls cannot be tested)

(2) don't add anything to math.h for now, only have
    the abi symbols.

if it's ok to backport public header changes then (2)
should work: then vectorization is not supported for
now, but e.g. if gcc-10 has the right support we can
conditionally add the header magic to math.h (and the
fortran module) later and backport that change to
glibc-2.30, potentially together with improved
algorithms (conditionally compiled with gcc-10).

in glibc-2.30 the testing can be conditional on attr
aarch64_vector_pcs support (which should work with
current gcc-9, the lazy binding issue is only solved
in trunk gcc yet, but that's not important for testing).

note that current math/test-math-vector.h provides a
declaration for vector functions, on aarch64 the
declaration is wrong, it needs the aarch64_vector_pcs
attribute:

/* Wrapper from scalar to vector function.  */
#define VECTOR_WRAPPER(scalar_func, vector_func) \
extern VEC_TYPE vector_func (VEC_TYPE);         \
FLOAT scalar_func (FLOAT x)                     \
{                                               \
...

if backporting public header changes is problematic
then this has to wait for another release.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]