From: David Edelsohn <dje.gcc@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [PATCH] powerpc64le: Add single instruction math functions
Date: Thu, 29 Jun 2017 13:00:51 -0400 [thread overview]
Message-ID: <CAGWvnykqTCEt70wRZ7_XacPLaxVN-CFzzs2rcC=t2NejJmvX2w@mail.gmail.com> (raw)
In-Reply-To: <20170629160544.GE1627@brightrain.aerifal.cx>
On Thu, Jun 29, 2017 at 12:05 PM, Rich Felker <dalias@libc.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@libc.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 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
next prev parent reply other threads:[~2017-06-29 17:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 14:53 David Edelsohn
2017-06-23 19:35 ` Rich Felker
2017-06-23 19:53 ` David Edelsohn
2017-06-24 0:46 ` A. Wilcox
2017-06-24 0:55 ` Rich Felker
2017-06-24 3:05 ` David Edelsohn
2017-06-24 3:32 ` Rich Felker
2017-06-24 3:38 ` A. Wilcox
2017-06-24 20:53 ` David Edelsohn
2017-06-24 22:44 ` Rich Felker
2017-06-24 23:57 ` A. Wilcox
2017-06-25 0:10 ` Rich Felker
2017-06-25 1:41 ` Rich Felker
2017-06-29 13:49 ` David Edelsohn
2017-06-29 16:05 ` Rich Felker
2017-06-29 17:00 ` David Edelsohn [this message]
2017-06-29 17:59 ` Rich Felker
2017-06-30 1:07 ` David Edelsohn
2017-06-30 2:11 ` Rich Felker
2017-06-25 3:24 ` David Edelsohn
2017-06-25 14:28 ` Rich Felker
2017-06-25 14:56 ` David Edelsohn
2018-09-27 22:53 ` A. Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGWvnykqTCEt70wRZ7_XacPLaxVN-CFzzs2rcC=t2NejJmvX2w@mail.gmail.com' \
--to=dje.gcc@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).