On 2/25/20 12:45 PM, Segher Boessenkool wrote:
Hi!
On Tue, Feb 25, 2020 at 04:53:17PM +0000, GT wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 23, 2020 11:45 AM, Bill Schmidt <wschm...@linux.ibm.com>
wrote:
As I just wrote on gcc-patches, we should disable libmvec for powerpc64.
The vector ABI as written isn't compatible with ELFv1. We would need
a modified ABI that doesn't allow homogeneous aggregates of vectors to
be returned in registers in order to support ELFv1. I do not believe
that is worth pursuing until and unless there is demand for it (which
I do not expect).
Are we all agreed that the POWER Vector Function ABI will be implemented only
for powerpc64le?
I do not agree.
I don't agree we should have a new ABI, and an API (which this *is* as
far as I can tell) works fine on *any* ABI. Homogeneous aggregates has
nothing to do with anything either.
It is fine to only *support* powerpc64le-linux, sure. But don't fragment
the implementation, it only hurts, never helps -- we will end up having
to support ten or twenty different compilers, instead of one compiler
with a few (mostly) orthogonal variations. And yes, we should also test
everything everywhere, whenever reasonable.
Thanks, Segher. Let me ask for some clarification here on how you'd like
us to proceed.
The reason that homogeneous aggregates matter (at least somewhat) is that
the ABI ^H^H^H^HAPI requires establishing a calling convention and a name-
mangling formula that includes the length of parameters and return values.
Since ELFv2 and ELFv1 do not have the same calling convention, and ELFv2
has a superior one, we chose to use ELFv2's calling convention and make use
of homogeneous aggregates for return values in registers for the case of
vectorized sincos.
Please look at the document to see the constraints we're under to fit into
the different OpenMP clauses and attributes. It seems to me that we can
only define this for both powerpc64 and powerpc64le by establishing two
different calling conventions, which provides two different vector length
calculations for the sincos return value, and therefore requires two
different function implementations with different mangled names. (Either
that, or we cripple vectorized sincos by requiring it to return values
through memory.)
Now, we can either write a document that handles both cases now (describes
both calling conventions), and force glibc to have two different functions at
least for the sincos case; or we can restrict this particular document to
ELFv2 and leave open the possibility of writing a very similar but slightly
different document for ELFv1 at such time as someone wants to use ELFv1 for
libmvec. I'd personally rather push that extra work out until we know
there's a market for it. That is, I don't want to preclude its use for
ELFv1, but this *particular* API is specific to ELFv2, so we need to
acknowledge that in the code.
Ultimately it's your call, but if we need to rewrite the ABI/API we're
going to need concrete proposals for how to do that.
Thanks,
Bill
For the glibc side I have no opinion.
Segher
