Date: Thu, 29 Jun 2017 13:00:51 -0400 From: David Edelsohn <dje.gcc@...il.com> To: musl@...ts.openwall.com Subject: Re: [PATCH] powerpc64le: Add single instruction math functions On Thu, Jun 29, 2017 at 12:05 PM, Rich Felker <dalias@...c.org> 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 <dalias@...c.org> wrote: >> > On Sat, Jun 24, 2017 at 06:57:23PM -0500, A. Wilcox wrote: >> >> Except Adélie, 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=power6 (specific lower ISA) or >> >> - -mcpu=powerpc64 (generic) will affect its code output when it sees >> >> - -mabi=elfv2. 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 happen >> > >> > 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=elfv2). 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 18.104.22.168 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
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.