Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170625014151.GB1627@brightrain.aerifal.cx>
Date: Sat, 24 Jun 2017 21:41:51 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] powerpc64le: Add single instruction math functions

On Sat, Jun 24, 2017 at 08:10:24PM -0400, Rich Felker 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 just did a quick review (grep -r ELFv2 gcc/config/rs6000) and I
don't see anything that would cause gcc to generate code for a
different isa level than it otherwise would. The option purely
controls the calling convention and related issues.

One unfortunate thing I did discover in the process is that neither
powerpc64 ABI admits sibcall (tail call) to a function that's not
local (static or hidden/protected). This is a consequence of the ABI
GOT register being call-preserved rather than call-clobbered. This is
a common design issue (mistake IMO) affecting several archs, including
SH in the default ABI (but not in the FDPIC ABI, which made the choice
to change the GOT register to call-clobbered).

Rich

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.