[all-commits] [llvm/llvm-project] 4520b4: MIPS/libunwind: Use -mfp64 if compiler is FPXX (#6...

[YunQiang Su via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4520b478d2512b0f39764e0464dcb4cb961845b5
      https://github.com/llvm/llvm-project/commit/4520b478d2512b0f39764e0464dcb4cb961845b5
  Author: YunQiang Su <syq at debian.org>
  Date:   2024-02-08 (Thu, 08 Feb 2024)

  Changed paths:
    M libunwind/CMakeLists.txt

  Log Message:
  -----------
  MIPS/libunwind: Use -mfp64 if compiler is FPXX (#68521)

Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is
that, FP64 and FP32 have different way to save/restore FPRs. If
libunwind is built as FPXX, we have no idea which one should we use.

It's not due to the code bug, but rather the nature of FPXX.
FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0
(FP32).
So that FPXX binaries can link with both FP64 and FP32 ones, aka.
    FPXX + FP32 -> FP32
    FPXX + FP64 -> FP64

While for libunwind, we should save/restore all of FPRs. If we use FPXX,
we can only save/restore a common subset of FPRs, instead of superset.

If libunwind is built as FP64, it will interoperatable with FPXX/FP64
APPs, and if it is built as FP32, it will interoperatable with
FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are
FP32.

So if the compiler is FPXX, which is the default value of most
toolchain, let's switch it to FP64.

Co-authored-by: YunQiang Su <yunqiang.su at cipunited.com>