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

[simon_tatham]

Summary

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.

[lenary]

From your description this sounds right, and GCC matches the new behaviour as far as I can see: https://godbolt.org/z/f1M41dhvv

Please can you add a release note when you land this, as this is a breaking change?

[simon_tatham]

Added draft release notes, and an extra comment in the modified test file.

clang/docs/ReleaseNotes.rst

 ----------------------------
 
 DWARF Support in Clang
 ----------------------
 
 Arm and AArch64 Support in Clang
 --------------------------------
 
+* The hard-float ABI is now available in Armv8.1-M configurations that
+  have integer MVE instructions (and therefore have FP registers) but
+  no scalar or vector floating point computation. Previously, trying
+  to select the hard-float ABI on such a target (via
+  ``-mfloat-abi=hard`` or a triple ending in ``hf``) would silently
+  use the soft-float ABI instead.
+
 Floating Point Support in Clang
 -------------------------------
 
 Internal API Changes
 --------------------
 
 Build System Changes
 --------------------

llvm/docs/ReleaseNotes.rst

 ------------------------------
 
 Changes to the AMDGPU Backend
 -----------------------------
 
 Changes to the ARM Backend
 --------------------------
 
+- The hard-float ABI is now available in Armv8.1-M configurations that
+  have integer MVE instructions (and therefore have FP registers) but
+  no scalar or vector floating point computation.
+
 Changes to the AVR Backend
 --------------------------
 
 * ...
 
 Changes to the DirectX Backend
 ------------------------------
 

llvm/lib/Target/ARM/ARMFastISel.cpp

if (Subtarget->hasVFP2Base() && !isVarArg) {
       // For AAPCS ABI targets, just use VFP variant of the calling convention.
       return (Return ? RetCC_ARM_AAPCS_VFP : CC_ARM_AAPCS_VFP);
     }
     [[fallthrough]];
   case CallingConv::C:
   case CallingConv::CXX_FAST_TLS:
     // Use target triple & subtarget features to do actual dispatch.
     if (Subtarget->isAAPCS_ABI()) {
-      if (Subtarget->hasVFP2Base() &&
+      if (Subtarget->hasFPRegs() &&
           TM.Options.FloatABIType == FloatABI::Hard && !isVarArg)
         return (Return ? RetCC_ARM_AAPCS_VFP: CC_ARM_AAPCS_VFP);
       else
         return (Return ? RetCC_ARM_AAPCS: CC_ARM_AAPCS);
     } else {
       return (Return ? RetCC_ARM_APCS: CC_ARM_APCS);
     }
   case CallingConv::ARM_AAPCS_VFP:

llvm/lib/Target/ARM/ARMISelLowering.cpp

ARMTargetLowering::getEffectiveCallingConv(CallingConv::ID CC,
   case CallingConv::ARM_AAPCS_VFP:
   case CallingConv::Swift:
   case CallingConv::SwiftTail:
     return isVarArg ? CallingConv::ARM_AAPCS : CallingConv::ARM_AAPCS_VFP;
   case CallingConv::C:
   case CallingConv::Tail:
     if (!Subtarget->isAAPCS_ABI())
       return CallingConv::ARM_APCS;
-    else if (Subtarget->hasVFP2Base() && !Subtarget->isThumb1Only() &&
+    else if (Subtarget->hasFPRegs() && !Subtarget->isThumb1Only() &&
              getTargetMachine().Options.FloatABIType == FloatABI::Hard &&
              !isVarArg)
       return CallingConv::ARM_AAPCS_VFP;
     else
       return CallingConv::ARM_AAPCS;
   case CallingConv::Fast:
   case CallingConv::CXX_FAST_TLS:
     if (!Subtarget->isAAPCS_ABI()) {

llvm/test/CodeGen/Thumb2/float-ops.ll

 ; DP: vdiv.f64  d0, d0, d1
   %0 = fdiv double %a, %b
   ret double %0
 }
 
 define float @rem_f(float %a, float %b) {
 entry:
 ; CHECK-LABEL: rem_f:
-; NONE: bl fmodf
+; NONE: {{b|bl}} fmodf
 ; HARD: b fmodf
   %0 = frem float %a, %b
   ret float %0
 }
 
 define double @rem_d(double %a, double %b) {
 entry:
 ; CHECK-LABEL: rem_d:
-; NONE: bl fmod
+; NONE: {{b|bl}} fmod
 ; HARD: b fmod
   %0 = frem double %a, %b
   ret double %0
 }
 
+; In the ONLYREGS case (where we have integer MVE but no floating
+; point), we still expect the hard float ABI, because we asked for it
+; in the triple, and since the FP registers exist, it's possible to
+; use them to pass arguments. So the generated code should load the
+; return value into s0, not r0. Similarly for the other load and store
+; tests.
 define float @load_f(ptr %a) {
 entry:
 ; CHECK-LABEL: load_f:
-; NONE: ldr r0, [r0]
+; NOREGS: ldr r0, [r0]
+; ONLYREGS: vldr s0, [r0]
 ; HARD: vldr s0, [r0]
   %0 = load float, ptr %a, align 4
   ret float %0
 }
 
 define double @load_d(ptr %a) {
 entry:
 ; CHECK-LABEL: load_d:
 ; NOREGS: ldm r0, {r0, r1}
 ; ONLYREGS: vldr d0, [r0]
 ; HARD: vldr d0, [r0]
   %0 = load double, ptr %a, align 8
   ret double %0
 }
 
 define void @store_f(ptr %a, float %b) {
 entry:
 ; CHECK-LABEL: store_f:
-; NONE: str r1, [r0]
+; NOREGS: str r1, [r0]
+; ONLYREGS: vstr s0, [r0]
 ; HARD: vstr s0, [r0]
   store float %b, ptr %a, align 4
   ret void
 }
 
 define void @store_d(ptr %a, double %b) {
 entry:
 ; CHECK-LABEL: store_d:
 ; NOREGS: strd r2, r3, [r0]
-; ONLYREGS: strd r2, r3, [r0]
+; ONLYREGS: vstr d0, [r0]
 ; HARD: vstr d0, [r0]
   store double %b, ptr %a, align 8
   ret void
 }
 
 define double @f_to_d(float %a) {
 ; CHECK-LABEL: f_to_d:
 ; NONE: bl __aeabi_f2d

 ; SP: bl __aeabi_ui2d
 ; DP: vcvt.f64.u32 d0, s0
   %1 = uitofp i32 %a to double
   ret double %1
 }
 
 define float @bitcast_i_to_f(i32 %a) {
 ; CHECK-LABEL: bitcast_i_to_f:
-; NONE-NOT: mov
+; NOREGS-NOT: mov
+; ONLYREGS: vmov s0, r0
 ; HARD: vmov s0, r0
   %1 = bitcast i32 %a to float
   ret float %1
 }
 
 define double @bitcast_i_to_d(i64 %a) {
 ; CHECK-LABEL: bitcast_i_to_d:
-; NONE-NOT: mov
+; NOREGS-NOT: mov
+; ONLYREGS: vmov d0, r0, r1
 ; HARD: vmov d0, r0, r1
-  %1 = bitcast i64 %a to double
   ret double %1
 }
 
 define i32 @bitcast_f_to_i(float %a) {
 ; CHECK-LABEL: bitcast_f_to_i:
-; NONE-NOT: mov
+; NOREGS-NOT: mov
+; ONLYREGS: vmov r0, s0
 ; HARD: vmov r0, s0
   %1 = bitcast float %a to i32
   ret i32 %1
 }
 
 define i64 @bitcast_d_to_i(double %a) {
 ; CHECK-LABEL: bitcast_d_to_i:
-; NONE-NOT: mov
+; NOREGS-NOT: mov
+; ONLYREGS: vmov r0, r1, d0
 ; HARD: vmov r0, r1, d0
   %1 = bitcast double %a to i64
   ret i64 %1
 }
 
 define float @select_f(float %a, float %b, i1 %c) {
 ; CHECK-LABEL: select_f:
 ; NOREGS: lsls    r2, r2, #31
 ; NOREGS: moveq   r0, r1
-; ONLYREGS: lsls    r2, r2, #31
-; ONLYREGS: vmovne.f32      s2, s0
+; ONLYREGS: lsls    r0, r0, #31
+; ONLYREGS: vmovne.f32      s1, s0
 ; HARD: lsls    r0, r0, #31
 ; VFP4-ALL: vmovne.f32      s1, s0
 ; VFP4-ALL: vmov.f32        s0, s1
 ; FP-ARMv8: vseleq.f32 s0, s1, s0
   %1 = select i1 %c, float %a, float %b
   ret float %1
 }
 
 define double @select_d(double %a, double %b, i1 %c) {
 ; CHECK-LABEL: select_d:
-; NONE: ldr{{(.w)?}}     [[REG:r[0-9]+]], [sp]
-; NONE: ands    [[REG]], [[REG]], #1
+; NOREGS: ldr{{(.w)?}}     [[REG:r[0-9]+]], [sp]
+; NOREGS: ands    [[REG]], [[REG]], #1
+; ONLYREGS: ands    r0, r0, #1
 ; NOREGS-DAG: moveq   r0, r2
 ; NOREGS-DAG: moveq   r1, r3
 ; ONLYREGS-DAG: csel   r0, r0, r2
 ; ONLYREGS-DAG: csel   r1, r1, r3
 ; SP: ands r0, r0, #1
 ; SP-DAG: vmov [[ALO:r[0-9]+]], [[AHI:r[0-9]+]], d0
 ; SP-DAG: vmov [[BLO:r[0-9]+]], [[BHI:r[0-9]+]], d1
 ; SP: itt ne