[libc-dev] [musl] Re: ppc64le and 32-bit LE userland compatibility
Segher Boessenkool via libc-dev
libc-dev at lists.llvm.org
Fri Jun 5 16:45:23 PDT 2020
On Fri, Jun 05, 2020 at 01:50:46PM -0400, Rich Felker wrote:
> On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> > > I'm also not really all that convinced that vectors make a huge difference in non-specialized code (autovectorization still has a way to go)
> > They do make a huge difference, depending on the application of course.
> > But VSX is not just vectors even: it also gives you twice as many
> > floating point scalars (64 now), and in newer versions of the ISA it can
> > be beneficially used for integer scalars even.
> Vectorization is useful for a lot of things, and I'm sure there are
> specialized workloads that benefit from 64 scalars, but I've never
> encountered a place where having more than 16 registers made a
> practical difference.
20 years ago 32 FP registers was already often a limitation, making FFT
and similar kernels almost twice slower than they could otherwise be.
Things are only *worse* with short vectors, not better. In general with
floating point data you need more registers (because you have more state
to look at concurrently) than with integer data.
*Of course* having 64 floating point registers does not matter if your
whole program only ever uses three floating point values, total, let
> The fact that there are specialized areas where this stuff matters
> does not imply there aren't huge domains where it's completely
There are very few domains where ISA 2.07 does not have significant
advantages over ISA 2.01. That is Power8 vs. Power4.
> > No, that is exactly the point of requiring ISA 2.07. Anything can use
> > ISA 2.07 (incl. VSX) without checking first, and without having a
> > fallback to some other implementation. Going from ISA 2.01 to 2.07 is
> > more than a decade of improvements, it is not trivial at all.
> This only affects code that's non-portable and PPC-specific, which a
No, it does not. It is not only about vector registers, either.
> I think a lot of the unnecessary fighting on this topic is arising
> from differences of opinion over what an ABI entails. I would call
> what you're talking about a "platform" and more of a platform-specific
> *API* than an ABI -- it's about guarantees of interfaces available to
> the programmer, not implementation details of linkage.
No, this is very much about the ABI. The B stands for Binary. Which
is what this is about.
More information about the libc-dev