This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Aarch64: Add simd exp/expf functions
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: nd <nd at arm dot com>, Steve Ellcey <sellcey at marvell dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 21 Jun 2019 11:51:52 +0000
- Subject: Re: [PATCH v2] Aarch64: Add simd exp/expf functions
- References: <bd1b565d471b5549f332a53cf450c91e38634d5a.camel@marvell.com> <06801b7f-070f-c6fd-19e3-8121aa253e1f@arm.com> <be47008e-8b94-6eba-da7d-0edfe9ad7c11@arm.com> <878stvyzty.fsf@oldenburg2.str.redhat.com>
On 21/06/2019 11:53, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> 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).
>
> To be clear, it's not a dummy implementation, but one with assembler
> trampolines which adjust the calling convention?
>
> So it will be fully functional, just rather slow?
yes, it's fully functional and call abi conform.
i call it dummy because i would not add vector
code, just fall back to scalar calls in the asm.
i guess the asm could be a trampoline that calls
vector c code following the base call convention,
but we don't have reasonable vector c code yet.
either way we can have abi symbols that follow
the right call convention using asm with an old
compiler.
what we cannot have is declarations that only
specify the availability of the specific symbols
we define.