[all-commits] [llvm/llvm-project] bae7cf: [ELF][PPC64] Synthesize _savegpr[01]_{14..31} and ...

[Fangrui Song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: bae7cf674621b5892a036fabe77692a59e2b115b
      https://github.com/llvm/llvm-project/commit/bae7cf674621b5892a036fabe77692a59e2b115b
  Author: Fangrui Song <maskray at google.com>
  Date:   2020-05-26 (Tue, 26 May 2020)

  Changed paths:
    M lld/ELF/Arch/PPC64.cpp
    M lld/ELF/Target.h
    M lld/ELF/Writer.cpp
    A lld/test/ELF/ppc64-restgpr0.s
    A lld/test/ELF/ppc64-restgpr1.s
    A lld/test/ELF/ppc64-savegpr0.s
    A lld/test/ELF/ppc64-savegpr1.s
    A lld/test/ELF/ppc64-saveres.s

  Log Message:
  -----------
  [ELF][PPC64] Synthesize _savegpr[01]_{14..31} and _restgpr[01]_{14..31}

In the 64-bit ELF V2 API Specification: Power Architecture, 2.3.3.1. GPR
Save and Restore Functions defines some special functions which may be
referenced by GCC produced assembly (LLVM does not reference them).

With GCC -Os, when the number of call-saved registers exceeds a certain
threshold, GCC generates `_savegpr0_* _restgpr0_*` calls and expects the
linker to define them. See
https://sourceware.org/pipermail/binutils/2002-February/017444.html and
https://sourceware.org/pipermail/binutils/2004-August/036765.html . This
is weird because libgcc.a would be the natural place. However, the linker
generation approach has the advantage that the linker can generate
multiple copies to avoid long branch thunks. We don't consider the
advantage significant enough to complicate our trunk implementation, so
we take a simple approach.

* Check whether `_savegpr0_{14..31}` are used
* If yes, define needed symbols and add an InputSection with the code sequence.

`_savegpr1_*` `_restgpr0_*` and `_restgpr1_*` are similar.

Reviewed By: sfertile

Differential Revision: https://reviews.llvm.org/D79977