[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Jun 2020 12:27:02 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Daniel Kolesa <daniel@...aforge.org>
Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
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 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.
> 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.
> As for other instructions, fair enough, but from my rough testing, it doesn't make such a massive difference for average case
That depends on what you call the average case. Code that is control
and memory-bound will not benefit much from *anything* :-)
> (and where it does, one can always rebuild their thing with CFLAGS=-mcpu=power9)
Yeah, but it helps quite a bit if your system (shared) libraries get all
improvements they can as well.
I'm not trying to dissuade you from not requiring VSX and 2.07 -- this
sounds like your best option, given the constraints. I'm just saying
the cost is not trivial (even ignoring the ABI divergence).
> > The target name allows to make such distinctions: this could for example
> > be powerpc64-*-linux-void (maybe I put the distinction in the wrong
> > part of the name here? The glibc people will know better, and "void" is
> > probably not a great name anyway).
>
> Hm, I'm not a huge fan of putting ABI specifics in the triplet, it feels wrong - there is no precedent for it with POWER (ARM did it with EABI though),
Maybe look at what the various BSDs use? We do have things like this.
> the last part should remain 'gnu' as it's still glibc; besides, gcc is compiled for exactly one target triplet, and traditionally with ppc compilers it's always been possible to target everything with just one compiler (endian, 32bit, 64bit, abi...).
This isn't completely true.
Yes, the compiler allows you to change word size, endianness, ABI, some
more things. That does not mean you can actually build working binaries
for all resulting combinations. As a trivial example, it will still
pick up the same libraries from the same library paths usually, and
those will spectacularly fail to work.
We are biarch for some targets, which means that both powerpc-linux
targets and powerpc64-linux targets can actually handle both of those,
with just -m32 or -m64 needed to switch which configuration is used.
But you cannot magically transparently switch to many other
configurations: for those, you just build a separate toolchain for that
specfic (variant) configuration, in the general case.
> The best way would probably be adding a new -mabi, e.g. -mabi=elfv2-novsx (just an example), which would behave exactly like -mabi=elfv2, except it'd emit some extra detection macro
Yeah, that sounds like a good idea. Patches welcome :-)
(A separate target name is still needed, but this will make development
simpler for sure).
Segher
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.
