[Syssw-elfv2abi] Vector Function ABI for Power8 VSX SIMD
System SW WG
syssw-elfv2abi at mailinglist.openpowerfoundation.org
Tue Dec 4 16:54:56 UTC 2018
I did not realize until just now that your response was meant for me. My
mistake. My name is Bert Tenjy and I am ready to get started on this task.
Please let me know your recommendation for how to proceed. I have spent
time studying the x86_64 implementation and I could generate a list of the
tasks needed to complete the Power8 VSX version. If that is of any help.
bert.tenjy at gmail.com
On Wed, Sep 12, 2018 at 3:26 PM System SW WG <
syssw-elfv2abi at mailinglist.openpowerfoundation.org> wrote:
> Hi! I apologize for not responding sooner. I was away at a conference for
> a week and haven't been able to fully keep up with my email.
> On 9/4/18 3:40 PM, System SW WG wrote:
> >>> The reason for initiating this thread is an attempt to solve glibc
> >>> Bugzilla 20123.
> >>> Section 2.6 "Vector Function Name Mangling" of this glibc document:
> >>> https://sourceware.org/glibc/wiki/libmvec?
> >>> action=AttachFile&do=view&target=VectorABI.txt
> >>> shows how vector function names are generated from corresponding
> >>> scalar versions for x86_64 machines.
> > There is also the aarch64 ABI:
> >> GCC for Linux on Power does not yet support the OpenMP "simd" API
> >> at all, because implementation of libmvec per the bugzilla you pointed
> >> to is a prerequisite for this. There is a bounty open for this work,
> >> and there has been some small interest in it in the past, but so far
> >> nothing has been delivered.
> > Indeed. Bert is interested in that Bounty and is starting a discussion
> > the required ABI changes, e.g. function name mangling.
> >>> 1. How should we proceed in similarly specifying vector function
> >>> names for Power8 VSX machines?
> > I think we first need to answer another question: what is the best place
> > document the vector function name mangling? Should it be documented in
> > ELFv2 ABI?
> > Reminder: the ELFv2 ABI already documents the vector data types, vector
> > parameter passing and the vector register save area.
> > After answering that we need an initial RFC for vector function name
> > We definitely want to not diverge from what the community is already
> > whenever possible, e.g. order of fields, prefix and mask.
> > But we do need to discuss isa, length and parameters.
> Since this is not a language-specific ABI issue, I tend to agree that this
> ultimately the right place to publish it. Because of OpenPOWER
> for reviews of their published documents, I would recommend that we first
> develop this as an ABI supplement, which we can then bring forward to the
> Systems Software Workgroup as a modification to the ABI itself, after we
> agreed on the details. I'm currently the document owner and can shepherd
> through the process.
> >>> 2. I would expect that gcc (and other compilers) will need to be
> >>> patched in order to use the new vector functions. Is this a correct
> >>> assumption?
> > I don't think we'll need changes to parameter passing because we already
> > v2-13 reserved for that, but we may indeed need changes after libmvec is
> > implemented. Bill, does that make sense?
> We don't want to introduce any incompatibilities with the existing ABI.
> The libmvec API implementation for calls must also be compatible with the
> existing ABI; there is no reason to introduce costs for "impedance
> at the libmvec API sites. I don't see why this would be necessary anyway.
> No new types will be created so far as I can see.
> Once the function name mangling is determined, implementation is just
> within each compiler, so I'm not sure what other changes would be needed
> after libmvec is implemented. Can you provide a specific example?
> It is likely that we will want to rather closely follow the mangling style
> of the existing architecture documents (AMD, AArch64) to allow for
> even if some features aren't present in Power at this writing. For
> <mask> from AMD makes no sense today, but could make sense at some future
> time. We will want this to be as flexible as possible.
> Apparently sending via the mailing list has introduced anonymity, so I'm
> not sure who I'm speaking with. :-) But I will be very happy to work with
> you throughout this process.
> Bill Schmidt, Ph.D.
> GCC Architect for Linux on Power
> IBM Linux Technology Center
> wschmidt at linux.ibm.com
> Syssw-elfv2abi mailing list
> Syssw-elfv2abi at mailinglist.openpowerfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Syssw-elfv2abi