[all-commits] [llvm/llvm-project] 60ea6f: [ARM] Allow selecting hard-float ABI in integer-on...

[Simon Tatham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 60ea6f35a270d11c91770a2fc366888e7d3859f4
      https://github.com/llvm/llvm-project/commit/60ea6f35a270d11c91770a2fc366888e7d3859f4
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2023-02-01 (Wed, 01 Feb 2023)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M llvm/docs/ReleaseNotes.rst
    M llvm/lib/Target/ARM/ARMFastISel.cpp
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/test/CodeGen/Thumb2/float-ops.ll

  Log Message:
  -----------
  [ARM] Allow selecting hard-float ABI in integer-only MVE.

Armv8.1-M can be configured to support the integer subset of the MVE
vector instructions, and no floating point. In that situation, the FP
and vector registers still exist, and so do the load, store and move
instructions that transfer data in and out of them. So there's no
reason the hard floating point ABI can't be supported, and you might
reasonably want to use it, for the sake of intrinsics-based code
passing explicit MVE vector types between functions.

But the selection of the hard float ABI in the backend was gated on
Subtarget->hasVFP2Base(), which is false in the case of integer MVE
and no FP.

As a result, you'd silently get the soft float ABI even if you
deliberately tried to select it, e.g. with clang options such as
--target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+nofp+mve

The hard float ABI should have been gated on the weaker condition
Subtarget->hasFPRegs(), because the only requirement for being able to
pass arguments in the FP registers is that the registers themselves
should exist.

I haven't added a new test, because changing the existing
CodeGen/Thumb2/float-ops.ll test seemed sufficient. But I've added a
comment explaining why the results are expected to be what they are.

Reviewed By: lenary

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