[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Jun 2020 13:50:46 -0400
From: Rich Felker <dalias@...c.org>
To: Segher Boessenkool <segher@...nel.crashing.org>
Cc: Daniel Kolesa <daniel@...aforge.org>, musl@...ts.openwall.com,
Michal Suchánek <msuchanek@...e.de>,
Joseph Myers <joseph@...esourcery.com>, 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 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires VSX - I don't think compiling for 970 introduces any actual differences. There will be omissions, yes - but then the more accurate thing would be to say that a subset of ELFv2 is used, rather than it being a different ABI per se.
> > >
> > > Two big things are that binaries that someone else made are supposed to
> > > work for you as well -- including binaries using VSX registers, or any
> > > instructions that require ISA 2.07 (or some older ISA after 970). This
> > > includes DSOs (shared libraries). So for a distribution this means that
> > > they will not use VSX *anywhere*, or only in very specialised things.
> > > That is a many-years setback, for people/situations where it could be
> > > used.
> >
> > Third party precompiled stuff doesn't really need to concern us, since none really exists.
>
> .... Yet. And if you claim you support ELFv2, not mentioning the ways
> your implementation deviates from it, users will be unhappy.
>
> > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
>
> Yeah, in mostly minor ways, but it all adds up for sure.
>
> > 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.
The fact that there are specialized areas where this stuff matters
does not imply there aren't huge domains where it's completely
irrelevant.
> > and code written to use vector instructions should probably check
> > auxval and take those paths at runtime.
>
> 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
lot of people have no interest in and don't care about. Any portable
code is going to either only use vectors via the compiler's choice to
vectorize or conditionally on being one of a set of supported targets
with a vector ISA it supports available. Anyone building for a target
that doesn't have them just gets the portable version of the code.
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.
Rich
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.
