From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11625 Path: news.gmane.org!.POSTED!not-for-mail From: David Edelsohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] powerpc64le: Add single instruction math functions Date: Thu, 29 Jun 2017 13:00:51 -0400 Message-ID: References: <20170623193533.GO1627@brightrain.aerifal.cx> <594DB66E.7030009@adelielinux.org> <594DDEC6.8030200@adelielinux.org> <594EFC63.3000707@adelielinux.org> <20170625001024.GA1627@brightrain.aerifal.cx> <20170629160544.GE1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1498755671 8511 195.159.176.226 (29 Jun 2017 17:01:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 17:01:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11638-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 29 19:01:03 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dQcoQ-0001mU-8X for gllmg-musl@m.gmane.org; Thu, 29 Jun 2017 19:01:02 +0200 Original-Received: (qmail 7515 invoked by uid 550); 29 Jun 2017 17:01:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7497 invoked from network); 29 Jun 2017 17:01:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=y7T9A81GjWtvuqj6w4AuoujLJIzKUvnCIit/1wl3MPw=; b=aLobVQVAZYyQA1DfUlwXg5PepOgnMKhktKN5Fd74d9kqiLSSKmOGwCieC8LJ8Y0MF4 wi4dNb4m9dxVvyfqgIhLo1+fzW0ds2mVxYAZa1LnZ+LmU33jBKX+B79uQYGnGMtbz1JC nsCLY/xezynTnn9mdlpU/HQp9zkmUUiqD/OwpLmlLJ1UPZewVqPD96zwpuOGhKKyMUFC qoM/EM7C+C+4rRd3UFP9zl3WlNTBm0sud1uNkUbF19XbuCef8VAhc30DMd1XDRkWLA7Z PfJhOixdbLA38VyQMUOUj7cnhhw8/7bbIN29PWeWZBQFTd0+GSDlvHiYgprc3bt5BL/n OM2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=y7T9A81GjWtvuqj6w4AuoujLJIzKUvnCIit/1wl3MPw=; b=RNVPzTMI04JMSfnT/+gPKm3ROH82JRi6NoWd/FaSz4YH6S6a02yiIZtqCq3HUuyrYk ZwLLL3uR2i6w0UbBQuZ27azQhD5lIUOuWa/DU9rdhG00UZlbyaXAjK4C6nahXvvdwY5A 5W+XEsY9p0HIFrSGlP+bhwzZacv23gRcAD99N8d2XEN3Tev1y+AxHqMQ8XwNP9BdkVl7 KDtfZ+97Rb7q+2bmdLxD/F/gO+pqBxocwp0PnMUtCJxIvDn3nzwS3H9g9B0yWJy3Ld3N SMyBzM4Hs940FU9eCIIY5JgpP5OJCSGb0cfYxm5d5FuvLHjWucgcj6Jb3RT/cZ3+LsWX cYLA== X-Gm-Message-State: AKS2vOy63zCCz56IM1InT0arrT5yshS0lfG71l5vFYCqHOOkVK4JL/jJ 8eCJBXrikYvySgNr+WEUp2Sol2+6dco+ X-Received: by 10.200.36.145 with SMTP id s17mr22172584qts.224.1498755652299; Thu, 29 Jun 2017 10:00:52 -0700 (PDT) In-Reply-To: <20170629160544.GE1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11625 Archived-At: On Thu, Jun 29, 2017 at 12:05 PM, Rich Felker wrote: > On Thu, Jun 29, 2017 at 09:49:34AM -0400, David Edelsohn wrote: >> On Sat, Jun 24, 2017 at 8:10 PM, Rich Felker wrote: >> > On Sat, Jun 24, 2017 at 06:57:23PM -0500, A. Wilcox wrote: >> >> Except Ad=C3=A9lie, Sabotage, and anyone who is creating their own >> >> environment without using a distribution. Or are you saying that GCC >> >> assumes LE with ELFv2? >> >> >> >> That is the primary reason I haven't shipped any PPC64 image yet. In >> >> addition to the usual badness of porting an entire distro worth of >> >> packages to a platform nobody has really used yet (had a similar time >> >> with musl on MIPS64 and 32-bit PowerPC), I'm a bit uneasy on the >> >> toolchain itself being able to understand what Rich has said. Since >> >> ELFv2 says that Power8 is the minimum ISA, gcc can do whatever it >> >> wants, and I'm not sure if -mcpu=3Dpower6 (specific lower ISA) or >> >> - -mcpu=3Dpowerpc64 (generic) will affect its code output when it see= s >> >> - -mabi=3Delfv2. So I'm going to need to put any PPC64 image through= a >> >> much more rigorous test than I did any other platform. >> > >> > I don't see any reason GCC would introduce a problem here. It should >> > always honor -march, and the default -march for the >> > powerpc64-linux-musl (elfv2 of course) toolchain I just built seems to >> > be POWER4 according to the predefined macros. >> > >> >> > I added the macro tests for portability and completeness. >> >> > >> >> > The only ports of Musl that will function on existing, supported, >> >> > big-endian PowerPC systems are the 32 bit "powerpc" port and an >> >> > unimplemented PPC64 BE ELFv1 port. >> >> >> >> >> >> Except Rich specifically said that he did not want an ELFv1 port for >> >> 64-bit PowerPC when I asked him, so I don't think that's going to hap= pen >> > >> > To clarify, my view is that it does not make sense to add a new port >> > that differs only in ABI, unless it's an ABI variant that's actually >> > necessary for reasonable support of some actual hardware (like >> > softfloat, fdpic for nommu, etc.). That is not the case here. >> >> A colleague of mine reminded me that ELFv2 ABI specifies POWER8 as the >> minimum hardware (not little-endian). > > This is a gratuitous requirement and has nothing to do with the > meaning of ELFv2 we're using (and likewise not with the gcc > --with-abi=3Delfv2). 2.1.1. Processor Architecture This ABI is predicated on, at a minimum, Power ISA version 2.7 and contains additional implementation characteristics. > >> The implementation of ELFv2 can >> operate on earlier hardware, but binaries may not be forward >> compatible because of VSX. Because of the calling convention of VSX >> registers in ELFv2, the stack may be corrupted if an application built >> without VSX support is linked with a library that does support VSX. >> One cannot mix and match musl libc built for POWER4 or PPC970 and musl >> libc built for POWER7. > > I don't think this is accurate. If it is then it's a serious bug we > need to fix, and it should have been discussed at the time the port > was added... This is not an implementation detail in the library, it is the calling convention in the compilers. > > Can you provide a citation for the usage of VSX registers in the > calling convention, and how you think that affects the stack? Table 2.22 Vector Register Roles in Section 2.2.1.1 Register Roles. The definition of volatile and non-volatile registers for vector registers affects the amount of stack allocated and the saving of non-volatile registers. What is the status of the PPC64LE math optimization patch? Thanks, David