Re: PPC64 libmvec sincos/sincosf ABI

[GT <tnggil at protonmail dot com>]

> 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.

How about this for the attribute specification:

__attribute__ ((__elfv2_aggregate_return__))

It's rather long, but there already exist attribute names of similar length, like
no_profile_instrument_function.

>
> 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.

I plan on reusing and adapting GCC's implementation of function cos as much as
possible. Nothing special about cos. Could just as well say reuse/adapt from
function sin.

Sincos differs from cos in that the scalar function has 2 extra input arguments;
the pointers to locations in which to store the sine and cosine results. So:

1. Prior to GCC making the vectorized cos call, arguments from multiple scalar
cosine calls are assembled into a single input vector argument to the vector cos
function. I think this part of code can be used almost verbatim for sincos. The
reason is that the first argument to sincos is passed by value and is in fact the
exact same value that would be passed to scalar sin and cos separately.

2. On return from the vector cos call, GCC extracts scalar results from the returned
vector output and assigns each to its respective scalar variable. Much of the code
here can be reused as long as a few changes are made:

i. When assembling the vector sincos call, each scalar call's 2nd and 3rd arguments
must be saved so that results will later be written to those locations.
ii. On return from the vector sincos, the code needs to account for the fact that scalar
results go to locations given by pointers rather than to named variables for cos.

Have I overlooked any significant issue?