[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.
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:
> >
> https://developer.arm.com/products/software-development-tools/hpc/arm-compiler-for-hpc/vector-function-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
> around
> > 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
> to
> > document the vector function name mangling?  Should it be documented in
> the
> > 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
> mangling.
> > We definitely want to not diverge from what the community is already
> using
> > 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
> is
> ultimately the right place to publish it.  Because of OpenPOWER
> requirements
> 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
> are
> agreed on the details.  I'm currently the document owner and can shepherd
> this
> 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
> have
> > 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
> matching"
> 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
> details
> 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
> expansion
> even if some features aren't present in Power at this writing.  For
> example,
> <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.
> Thanks!
> 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
> http://lists.mailinglist.openpowerfoundation.org/mailman/listinfo/syssw-elfv2abi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mailinglist.openpowerfoundation.org/pipermail/syssw-elfv2abi/attachments/20181204/7bed1e3b/attachment.html>

More information about the Syssw-elfv2abi mailing list