Implement PowerPC 64-bit native code backend for Linux
ClosedPublic

Authored by trommler on Jan 23 2015, 2:44 PM.

Details

Summary

Extend the PowerPC 32-bit native code generator for "64-bit
PowerPC ELF Application Binary Interface Supplement 1.9" by
Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
OpenPOWER ABI for Linux Supplement" by IBM.
The latter ABI is mainly used on POWER7/7+ and POWER8
Linux systems running in little-endian mode. The code generator
supports both static and dynamic linking. PowerPC 64-bit
code for ELF ABI 1.9 and 2 is mostly position independent
anyway, and thus so is all the code emitted by the code
generator. In other words, -fPIC does not make a difference.

rts/stg/SMP.h support is implemented.

Following the spirit of the introductory comment in
PPC/CodeGen.hs, the rest of the code is a straightforward
extension of the 32-bit implementation.

Limitations:

  • Code is generated only in the medium code model, which is also gcc's default
  • Local symbols are not accessed directly, which seems to also be the case for 32-bit
  • LLVM does not work, but this does not work on 32-bit either
  • Must use the system runtime linker in GHCi, because the GHC linker for "static" object files (rts/Linker.c) for PPC 64-bit is not implemented. The system runtime (dynamic) linker works.
  • The handling of the system stack (register 1) is not ELF- compliant so stack traces break. Instead of allocating a new stack frame, spill code should use the "official" spill area in the current stack frame and deallocation code should restore the back chain
  • DWARF support is missing

Fixes Trac #9863

Test Plan

validate (on powerpc, too)

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
trommler updated this revision to Diff 2160.Jan 23 2015, 2:44 PM
trommler retitled this revision from to Implement PowerPC 64-bit native code backend for Linux.
trommler added reviewers: austin, erikd.
trommler edited the test plan for this revision. (Show Details)
trommler updated the Trac tickets for this revision.
trommler updated this object.

Sick. Sad to see LE support missing (the POWER8 machine we have, frances.ghc.haskell.org is LE), but that can happen later.

In D629#17941, @austin wrote:

Sick. Sad to see LE support missing (the POWER8 machine we have, frances.ghc.haskell.org is LE), but that can happen later.

My development machine (PowerMac G5) has a 970FX PPC (approx. a POWER4) that does not support LE and some instructions required by ELF V2.

Most of the work to support POWER 8 LE is done in this patch. Missing is an implementation of ELF V2 PIC and C calling convention. I have read the specification and it does not look too difficult to implement it. Do you think I could get a login on frances?

erikd edited edge metadata.Jan 28 2015, 3:18 AM

Wow, impressive piece of work. I've checked out the code pretty thoroughly and nothing seems obvioulsy wrong or bad. I'll get my PPC machine up and running over the next couple of days and take this code for a spin.

trofi accepted this revision.Jan 28 2015, 9:11 AM
trofi edited edge metadata.

Most of tests pass even in 'fulltest' mode, which is really nice for a start.
Minor warts can be worked out later.

Thank you!

testsuite/tests/rts/all.T
40

Yeah, that test always fails on ppc32 (div 0 returns garbage).

This revision is now accepted and ready to land.Jan 28 2015, 9:11 AM
In D629#17941, @austin wrote:

Sick. Sad to see LE support missing (the POWER8 machine we have, frances.ghc.haskell.org is LE), but that can happen later.

My development machine (PowerMac G5) has a 970FX PPC (approx. a POWER4) that does not support LE and some instructions required by ELF V2.

Most of the work to support POWER 8 LE is done in this patch. Missing is an implementation of ELF V2 PIC and C calling convention. I have read the specification and it does not look too difficult to implement it. Do you think I could get a login on frances?

Email me a public key and I'll get it done.

simonmar edited edge metadata.Jan 28 2015, 2:18 PM

Amazing! I don't get the comment about tagged pointers - don't we always have to zero the tag bits of a pointer before dereferencing it?

Amazing! I don't get the comment about tagged pointers - don't we always have to zero the tag bits of a pointer before dereferencing it?

Sorry, the comment was missing a detailed explanation.

Let me explain:
When accessing a tagged pointer we need to remove the tag and I also do this for PPC 64-bit. On PPC removing the tag from a pointer is for free because load and store operations always have a displacement and we can use the displacement to remove (set to zero) the tag by subtracting it.

Now, here is the issue: Loads and stores for quantities of 32-bit and fewer use a D-Form instruction with a full 16 bit displacement. For some reason load and store instructions for 64-bit quantities use a DS-Form where the two least significant bits of the displacement must be set to zero. In other words displacements must be multiples of four and so we cannot use the "trick" to remove the tag "for free" as part of adding a displacement.

Amazing work!

I will test it on my Power8 machine next week.

Just one question though - will GHCi work on this version? (I didn't see it in OsSupportsGHCi)

In D629#21008, @arnons1 wrote:

Amazing work!

Thanks!

I will test it on my Power8 machine next week.

If you are running your POWER8 in big endian mode on Linux (ELF) you will be using this code. Otherwise you will end up with an unregisterised compiler that compiles via C.

Just one question though - will GHCi work on this version? (I didn't see it in OsSupportsGHCi)

Linux is supported, AIX not. You have to use dynamically linked libraries though, the RTS linker, which loads object files on other architectures, is not implemented for powerpc64 ELF. If you build ghc with the defaults you should be all set.

trommler updated this revision to Diff 2832.Apr 22 2015, 1:01 PM
trommler edited edge metadata.
  • rebase patch, it did not apply cleanly to HEAD anymore
  • refactor getAmode to remove large code duplication
  • remove old commented code
  • remove another comment on delay slots
  • Include GHCi on PowerPC 64-bit in config.mk

Just tried to apply this to todays HEAD and compile on power7 of gcc farm and the problem is that dll-split segfaults. I've just verified this is compiled with ghc-stage1 so actually with ghc with the patch... Have you seen that already? Thanks!

In D629#23786, @kgardas wrote:

Just tried to apply this to todays HEAD and compile on power7 of gcc farm and the problem is that dll-split segfaults. I've just verified this is compiled with ghc-stage1 so actually with ghc with the patch... Have you seen that already? Thanks!

I just rebased the commits onto HEAD (97d320f5) and the compile went straight through on my PowerMac G5 (970 MP) running openSUSE 13.2.

How can I reproduce the segfault you are seeing?

In D629#23786, @kgardas wrote:

Just tried to apply this to todays HEAD and compile on power7 of gcc farm and the problem is that dll-split segfaults. I've just verified this is compiled with ghc-stage1 so actually with ghc with the patch... Have you seen that already? Thanks!

I just rebased the commits onto HEAD (97d320f5) and the compile went straight through on my PowerMac G5 (970 MP) running openSUSE 13.2.

How can I reproduce the segfault you are seeing?

I will first rerun and see if your rebase fixed the issue. If not, then I'll update bootstrapping compiler which is some RC from 7.8.0 series. The OS is Fedora 18 with ghc 7.4.1 and gcc 4.7.2. I'll reply here or do you prefer another place?

trommler updated this object.May 26 2015, 3:59 PM
trommler updated this revision to Diff 2998.May 26 2015, 4:25 PM

Implement ELF 2.0 ABI for powerpc64le.

Add "Power Architecture 64-Bit ELF V2 ABI Specification --
OpenPOWER ABI for Linux Supplement" calling convention
to NCG.

trommler updated this object.May 26 2015, 4:31 PM

I tested with HEAD on POWER8/le and POWER7/be and it went fine. The builds build and testsuites provide just 158 and 159 testcase failures which is very nice for this development.

@austin, what do you think about landing this?

This revision was automatically updated to reflect the committed changes.