[PATCH] Add powerpc64-linux configuration options

[Michael Meissner]

On Thu, May 24, 2012 at 07:11:53PM -0400, David Edelsohn wrote:
> On Wed, May 23, 2012 at 6:36 PM, Michael Meissner
> <meissner@linux.vnet.ibm.com> wrote:
> > On powerpc64-linux systems that run on IBM servers, the 32-bit software
> > emulation library is not built with the Red Hat and SUSE distributions, but the
> > FSF sources still list it as a multilib. Â This patch adds a configuration
> > option (--disable-ppc64-swfloat) to disable building this library.
> >
> > We've also seen some performance issues where building the multilibs with the
> > -mstrict-align option causes slow downs. Â I vaguelly recall adding this option
> > in the 1995 time frame, because the 603, 604 systems of the day did not handle
> > unaligned accesses in little endian mode, and maybe some of the other embedded
> > chips did not handle unaligned accesses at all. Â This patch also adds an option
> > (--disable-ppc64-strict-align) to disable building the multilibs with
> > -mstrict-align.
> 
> I thought the use of -mstrict-align for multilibs was because of some
> re-use by embedded distros. That somehow one could build apps for
> embedded PowerPC processors without a full embedded cross-toolchain --
> just using the regular toolchain with an embedded target command line
> option and the base libraries already worked. I am not suggesting that
> (ab)use is appropriate, but I don't want to break embedded
> environments.

As I said, I believe the original motivation was that unaligned accesses did
not work in little endian mode, or for floating point but given it was 17 years
ago (and 4 or 5 different employers in my case), I don't remember the details
as much.

At least in the past, there are some differences between eabi programming and
Linux (2 small data pointers vs. 1, some alignment differences).

The first patch does this by keeping with the status quo and then if you want
to suppress the two features, adding options.  I could flip the sense of the
options, and make it default to no software floating point and no strict align.

Current SLES (Sles 10 and 11) and Red Hat (RHEL 5 and 6) right now disable
software floating emulation by applying a patch in their rpm spec files to
delete it.  In fact having the trunk still supporting software emulation causes
some problems as we build toolchains that use the host libraries.  The IBM
Advace Toolchain also eliminates the emulation libraries for the same reason.

I can't tell whether yellowdog linux compiles with the emulation library
multilib or not.

At the end of the day, any of the 3 proposals (counting the first patch and
swapping the defaults as a 3rd proposal) are fine with me.  It is simplest to
do the 2nd patch, but if we wanted to preserve the ability to do it, I would
suggest the first patch with the defaults set not to build the library or use
-mstrict-align would be best.

Alan does have a point that the MULTILIB_EXTRA_OPTS is broken for the default
libraries.  If you configure the compiler with a default for 64-bit, it is
mostly ok skipping the pic option or strict align.

> I agree that strict-align does not make sense for PPC64.
> 
> I believe that is what you are accomplishing with the second version
> of your patch, correct?

Yes, the second patch just does not build the library or use the -mstrict-align
option.  It is much simpler, but there may be somebody out there that depends
on the functionality.  I really don't know, one way or the other.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com	fax +1 (978) 399-6899