[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4ca9d8f4-4d61-4e99-969c-03a99e4fd3cc@www.fastmail.com>
Date: Fri, 05 Jun 2020 00:26:22 +0200
From: "Daniel Kolesa" <daniel@...aforge.org>
To: "Joseph Myers" <joseph@...esourcery.com>
Cc: "Segher Boessenkool" <segher@...nel.crashing.org>,
musl@...ts.openwall.com, "Rich Felker" <dalias@...c.org>,
Michal Suchánek <msuchanek@...e.de>,
libc-alpha@...rceware.org, eery@...erfox.es,
"Will Springer" <skirmisher@...tonmail.com>,
"Palmer Dabbelt via binutils" <binutils@...rceware.org>,
"via libc-dev" <libc-dev@...ts.llvm.org>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: Re: ppc64le and 32-bit LE userland compatibility
On Fri, Jun 5, 2020, at 00:08, Joseph Myers wrote:
> On Thu, 4 Jun 2020, Daniel Kolesa wrote:
>
> > The ELFv2 document specifies things like passing of quadruple precision
> > floats. Indeed, VSX is needed there, but that's not a concern if you
> > *don't* use quadruple precision floats.
>
> My understanding is that the registers used for argument passing are all
> ones that exactly correspond to the Vector registers in earlier
> instruction set versions. In other words, you could *in principle*
> produce an object, or a whole libm shared library, that (a) passes or
> receives _Float128 values in registers, (b) does not use any instructions
> beyond those available with -mcpu=970, (c) would work as intended whether
> executed on a 970 or on POWER8 and (d) when executed on POWER8, would
> fully interoperate with objects receiving or passing _Float128 values and
> compiled for POWER8 to use VSX instructions for that purpose. GCC may not
> support _Float128 for older processors, but that doesn't prevent you from
> maintaining patches to add such support. (But if you want to support
> those 64-bit processors that don't have Vector registers at all, you
> indeed can't use binary128 and interoperate with code using VSX for that
> format in POWER8.)
There's a potential userbase with 64-bit BE processors from Freescale/NXP that don't have any AltiVec support, I believe they are still in production - I'd like to retain support for these targets, as well as older IBM processors. The userland generally also supports that, and we've had multiple requests for support of this kind of hardware.
And while implementing it with just VMX may be possible, most hardware running this ABI wouldn't have any support for quad precision FP, and would perform better with using just double-precision.
We're not a commercial project, so we're just trying to support users within the FOSS community; I definitely wouldn't mind having this be just an ABI variant parallel to the others. Using 64-bit long doubles also has the benefit of being the same ABI as musl, which would enable things such as gcompat to work.
Either way I'll think about it some more and possibly prepare an RFC port. I'm definitely willing to put in the work and later maintenance effort if that's what it takes to make it happen.
>
> (Cf. how the Arm hard-float ABI variant works even on processors with
> single-precision-only VFP, because such processors still have the
> double-precision loads and stores although not double-precision
> arithmetic. When working on that ABI support in GCC some years ago, I
> also made sure that GNU vector types corresponding to NEON vector types
> were passed consistently for the hard-float ABI whether or not any vector
> instructions were present - thus, avoiding depending on the machine modes
> for those vector types because GCC could choose a different machine mode
> depending on the instructions available.)
>
> --
> Joseph S. Myers
> joseph@...esourcery.com
>
Daniel
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
