unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Bill Schmidt <wschmidt@linux.ibm.com>
To: GT <tnggil@protonmail.com>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: PPC64 libmvec sincos/sincosf ABI
Date: Fri, 20 Sep 2019 15:25:52 -0500	[thread overview]
Message-ID: <5115db44-7640-44f1-630f-c90992602fbb@linux.ibm.com> (raw)
In-Reply-To: <bPU5suQJKGq4tSJT5Ql-a4CHhOfAzI6bEPBnVxzjR5_MRWpTITv2LueySiGKZjGzI2lnmxgmk9bn6oXcfKUp6JXbsGkVpm5k0kuFUq2Mgzo=@protonmail.com>

On 9/20/19 2:25 PM, GT wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, August 8, 2019 11:25 AM, Bill Schmidt wschmidt@linux.ibm.com wrote:
>
>> 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.
> I believe we can now answer the issues that Joseph raised earlier in this thread.
> Those questions are here: https://sourceware.org/ml/libc-alpha/2019-08/msg00022.html
>
> The PowerPC64 double-precision vector sincos will have this as its prototype:
> struct sincosret _ZGVbN2v_sincos (vector double);
>
> The corresponding single-precision vector sincosf will have a prototype:
> struct sincosretf _ZGVbN4v_sincosf (vector float);
> -----------------------
>
> We also need a new attribute that will indicate when scalar sincos[f] in a loop can be vectorized using the newly redefined PowerPC64 vector sincos[f] functions. None of the existing attributes can be used since the technique used to return multiple values in registers is new AFAIU. So, Bill, are you the designer who can attest that what is agreed to here for the sincos API and ABI will be faithfully reflected in the ABI document?


Hi Bert,

Sure, I can work together with you on this.  I agree that a new 
attribute is needed.  The term we use for this in our existing ELFv2 ABI 
document is "homogeneous aggregates," so it would be good if the name of 
the attribute could reflect that the interface returns a homogeneous 
aggregate.  This is a bit of a mouthful, so may require some shortening.

As far as the new ABI document goes, I think we are looking to you to 
complete the proposal of interfaces, attributes, and so forth so that 
the document can be written.  I am the right person to work with on this.

Thanks!

Bill

>

  reply	other threads:[~2019-09-20 20:26 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
2019-09-20 19:25   ` GT
2019-09-20 20:25     ` Bill Schmidt [this message]
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=5115db44-7640-44f1-630f-c90992602fbb@linux.ibm.com \
    --to=wschmidt@linux.ibm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=tnggil@protonmail.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).