Following up on bug report 6943, this pull request provides native-code compilation support for the POWER/PowerPC architecture in 64-bit mode, both in big-endian (ppc64 in Debian's classification) and in little-endian (ppc64le).

Summary of changes

Starting with the existing power port of ocamlopt, which supports PPC32/Linux, PPC32/MacOSX and PPC64/MacOSX, this PR:

• Removes support for MacOSX (which no longer works on PowerPC machines) and historical remnants of a long-dead AIX port.
• Updates the 32-bit code generator with partial GDB debugging support (.loc and .cfi directives), and @plt relocations for semi-position-independent code (working around the limited excursion of the "branch and link" instruction).
• Updates the 64-bit code generator likewise.
• Adds support for little-endian execution in addition to big-endian.
• Adds support for the ELF PPC64 ABI version 1, as used in the ppc64 64-bit, big-endian configuration.
• Adds support for the ELF PPC64 ABI version 2, as used in the ppc64le 64-bit, little-endian configuration.

Comparison with RedHat's ports

RedHat already provides OCaml ports for ppc64 and ppc64le, developed in-house and/or in cooperation with IBM. Those ports were an excellent source of inspiration for the proposed code, explaining some of the subtleties of the ELF PPC64 ABIs. The proposed code significantly departs from RedHat's on three points:

• RedHat has 3 different architectures, in asmcomp/power, asmcomp/power64 and asmcomp/power64le, with copious duplication of code between these three directories. This is not maintainable in the long term. In contrast, the proposed code is one unified architecture, in asmcomp/power, and uses the "model" configuration variable to adapt between 32 and 64 bits, between big and little endian, and between the various ABIs. Code is factored out as much as possible.
• RedHat's PPC64 ports work hard to maintain the standard shape of PPC64 stack frames, including the back link between frames. This comes at some costs in code complexity. The proposed code uses a simpler shape of stack frames, similar to the one used in other OCaml code generators, and without back links. Appropriate .cfi directives are generated to enable GDB to walk the call stack as usual.
• RedHat's PPC64 ports do not use the bl function_symbol; nop idiom to call known OCaml functions, using more expensive indirect calls instead. (The idiom is specially optimized by the linker.) This is probably due to problems with tail calls. The proposed code solves these problems differently, using explicit saving and restoring of the TOC register r2, in a way that remains compatible with the idiom and its link-time optimization.

Status and testing

The new port, in its 3 configurations (ppc, ppc64, ppc64le), was tested under Debian 8.1, on a G5 PowerMac at Inria for the ppc and ppc64 configurations, and on a POWER8 virtual machine provided by RedHat Brno for the ppc64le configuration.

All tests from the OCaml test suite pass except one socket-related test that fails on the POWER8 VM, very probably because the VM is IPv6-only and the test is not IPv6-ready.

gprof-style profiling (ocamlopt -p) currently does not work on ppc64le, but it does not work with GCC either. I suspect a problem within Glibc, and reported it to Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794222).

The 32 and 64be configurations were also successfully tested on the CompCert compiler.

Maintainability

As a member of the OCaml core dev team, I should be able to support this port in the medium to long term, provided

• our 2005-vintage PowerMac G5 doesn't break (but those things are solidly built);
• IBM and RedHat keep providing POWER8 VMs as part of their OpenPOWER programme.

I am looking into the possibility of adding the PowerMac G5 to our continuous integration system.