From: Bill Schmidt <wschmidt@linux.ibm.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
"'GNU C Library'" <libc-alpha@sourceware.org>,
"tnggil@protonmail.com" <tnggil@protonmail.com>,
Joseph Myers <joseph@codesourcery.com>
Cc: nd <nd@arm.com>, Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Subject: Re: PPC64 libmvec sincos/sincosf ABI
Date: Thu, 8 Aug 2019 13:48:41 -0500 [thread overview]
Message-ID: <1730b1dd-9495-2f04-cbc7-4a957bc20a6a@linux.ibm.com> (raw)
In-Reply-To: <dd9a8fa9-e11a-7b2f-7ae6-a9dfb789cedf@linux.ibm.com>
On 8/8/19 10:25 AM, Bill Schmidt wrote:
> On 8/6/19 12:42 PM, Wilco Dijkstra wrote:
>> Hi,
>>
>>> 1. What is the best vector ABI (best performance) for sincos on PPC64?
>>> That may be a function of the particular vector instructions available on
>>> PPC64; the best choice of ABI on PPC64 need not correspond to the best
>>> choice on x86_64.
>> I don't think it is related to the target - the fastest ABI is one that avoids
>> unnecessary work. For example scalar sincos is slow due to the inefficient
>> ABI which forces the results through memory (fixing that gives a 50% speedup).
>>
>> Similarly for the vector ABI I think returning 2 vectors in registers will be the
>> fastest option in all cases. The actual vector instructions shouldn't affect the
>> ABI beyond the vector widths that can be supported.
>>
>> Wilco
>>
> Let me jump in here to answer a general question that I think Bert has
> had for a while.
>
> For the PPC64LE ABI, we should be returning everything through registers
> wherever possible. The ABI supports multiple return values of the same
> type (up to 8 vector return values, for example), using the same
> registers used for passing parameters. For simplicity in this example,
> I'll use the AltiVec-style types (vector double), but this works
> identically if you use more generically defined vector types.
>
> #include <altivec.h>
>
> struct sincosret
> {
> vector double sinvals;
> vector double cosvals;
> };
>
> struct sincosret
> mysincos (vector double a)
> {
> struct sincosret scr;
> scr.sinvals = a+a; // May be slightly incorrect
> scr.cosvals = a*a; // Ditto
> return scr;
> }
>
> This will result in the values being returned in VR2 and VR3:
>
> xvmuldp 35,34,34
> xvadddp 34,34,34
> blr
>
> This is preferable to returning values indirectly through memory, which
> on older POWER processors can result in stalls from the store and load
> being too close together and possibly executed out of order. The cost
> is pretty much negligible compared to the cost of computing sin/cos, but
> we might as well do it the best way that the ABI provides.
Important caveat to the above. This is the ELFv2 ABI, used for
little-endian. For the older ELFv1 ABI, the returned values will still
go through memory.
This doesn't restrict us from supporting ELFv1, but we just won't get
the benefit.
Thanks,
Bill
>
> Now, as I've said elsewhere, dealing with sincos in the -mveclibabi
> framework in GCC may be less than straightforward, due to the different
> description of the output types, but perhaps AArch64 has already laid
> some groundwork here. I'm not up to date on the pending patches.
>
> Hope this helps,
> Bill
>
next prev parent reply other threads:[~2019-08-08 18:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-06 17:42 PPC64 libmvec sincos/sincosf ABI Wilco Dijkstra
2019-08-06 20:31 ` Joseph Myers
2019-08-08 15:25 ` Bill Schmidt
2019-08-08 18:48 ` Bill Schmidt [this message]
2019-09-20 19:25 ` GT
2019-09-20 20:25 ` Bill Schmidt
2019-09-23 18:02 ` GT
2019-09-24 16:43 ` Bill Schmidt
-- strict thread matches above, loose matches on Subject: below --
2019-08-01 13:01 GT
2019-08-01 17:04 ` Joseph Myers
2019-08-07 21:17 ` Tulio Magno Quites Machado Filho
2019-08-08 13:33 ` Bill Schmidt
2019-08-08 15:48 ` GT
2019-08-08 15:56 ` Florian Weimer
2019-08-08 16:56 ` GT
2019-08-08 16:11 ` Bill Schmidt
2019-08-08 17:42 ` GT
2019-08-08 17:51 ` Bill Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1730b1dd-9495-2f04-cbc7-4a957bc20a6a@linux.ibm.com \
--to=wschmidt@linux.ibm.com \
--cc=Wilco.Dijkstra@arm.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
--cc=tnggil@protonmail.com \
--cc=tuliom@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).