From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4848 invoked from network); 5 Jun 2020 23:45:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Jun 2020 23:45:45 -0000 Received: (qmail 28143 invoked by uid 550); 5 Jun 2020 23:45:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28122 invoked from network); 5 Jun 2020 23:45:43 -0000 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 5 Jun 2020 18:45:23 -0500 From: Segher Boessenkool To: Rich Felker Cc: Daniel Kolesa , musl@lists.openwall.com, Michal =?iso-8859-1?Q?Such=E1nek?= , Joseph Myers , libc-alpha@sourceware.org, eery@paperfox.es, Will Springer , Palmer Dabbelt via binutils , via libc-dev , linuxppc-dev@lists.ozlabs.org Message-ID: <20200605234523.GU31009@gate.crashing.org> References: <20200604171232.GG31009@gate.crashing.org> <20200604171844.GO1079@brightrain.aerifal.cx> <20200604173312.GI31009@gate.crashing.org> <20200604211009.GK31009@gate.crashing.org> <60fa8bd7-2439-4403-a0eb-166a2fb49a4b@www.fastmail.com> <20200604233516.GM31009@gate.crashing.org> <17459c98-3bd3-4a5d-a828-993b6deef44f@www.fastmail.com> <20200605172702.GP31009@gate.crashing.org> <20200605175045.GW1079@brightrain.aerifal.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200605175045.GW1079@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility Hi! 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 alone concurrently. > The fact that there are specialized areas where this stuff matters > does not imply there aren't huge domains where it's completely > irrelevant. 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. Segher