[CodeGen][ARM] ARM runtime helper functions are not always soft-fp

[peter.smith]

Summary

The ARM Runtime ABI document (IHI0043) defines the AEABI floating point helper functions in section 4.1 Floating-point library. These functions always use the base PCS (soft-fp). However helper functions defined outside of this document such as the complex-number multiply and divide helpers are not covered by this requirement and should use hard-float PCS if the target is hard-float. All of the floating point helper functions that are explicitly soft float are expanded in the llvm ARM backend. This change makes clang not force the BuiltinCC to AAPCS for AAPCS_VFP.

With this change clang matches the behavior of gcc and the expected calling convention of the hard-float compiled compiler-rt and libgcc.a libraries as these functions do not have the attribute((pcs("aapcs"))).

fixes https://bugs.llvm.org/show_bug.cgi?id=28164
fixes test failures in compiler-rt for a hard-float target "divtc3_test.c, divdc3_test.c, divxc3_test.c"

I'm very new to clang so the way this has been fixed maybe a bit too simplistic. At present none of the builtins that produce calls in clang must use the base PCS. If clang ever needs to make a call to one of the AEABI defined functions that need base AAPCS then we'll need to identify the function when choosing a calling convention.

References:

• GCC list of functions that must be base AAPCS https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/arm/arm.c?view=co&content-type=text%2Fplain
• Runtime ABI for the ARM Architecture http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf

[compnerd]

Can you please add a test that shows that the AEABI functions are not given the wrong CC? Also, can you show that if someone also passes -meabi=gnu with a VFP target, that we still annotate the functions with the differing CC (since that should prefer the GNU functions over the AEABI functions).

[peter.smith]

In D35538#814008, @compnerd wrote:

Can you please add a test that shows that the AEABI functions are not given the wrong CC? Also, can you show that if someone also passes -meabi=gnu with a VFP target, that we still annotate the functions with the differing CC (since that should prefer the GNU functions over the AEABI functions).

Thanks for the comment. Can I just check my understanding before I proceed? In particular I think I need a bit more information about what -meabi=gnu is supposed to do.
I think tests to make sure the the floating point helper functions always use AAPCS is a good idea and I'll start working on that. At the moment I'm trying to work out the best way of doing this as this is all done in the ARM backend in llvm. My current favorite options are to compile and check the assembly in the clang test suite, or just check that the calls to the floating point helper functions are not emitted by clang and add a test to llvm to make sure that they have the correct calling convention. I'm currently tending towards the second option.

With respect to -meabi=gnu, this was added in clang under r252463 and llvm r252462. From tracing through the flag through ARMTargetMachine.cpp and ARMISelLowering.cpp it seems like all this flag does in llvm is to use memcpy, memmove and memset instead of aeabi_memcpy, aeabi_memmove and aeabi_memset respectively. These functions always use AAPCS calling convention, but as they do not take any floating point parameters it doesn't matter either way. As it stands the option won't have any effect on the use of other library functions for example doing a double precision divide with -meabi=gnu results in a call to aeabi_ddiv. Does this match your expectation of what -meabi=gnu is supposed to do? If it doesn't can you point me at a description? All that I could find externally was the -meabi option in the GNU assembler (there is no equivalent gcc option), the value of -meabi=gnu maps to EF_ARM_ABI_UNKNOWN which is intended for generation of pre ARM ABI objects.

I'll be on vacation for the next 3 days, I'll pick this back up next week.

[peter.smith]

I've added a clang test that will check that none of the floating point helper functions defined in the Runtime ABI for the ARM Architecture are directly called by clang. Given that the calling convention decisions for these helpers are made in llvm I think the best place for a test that the correct calling convention is in llvm. I'll start working on that and post in a separate review. Please let me know if I'm not on the right lines.

[compnerd]

I think that the approach is reasonable. However, the test needs tweaking. The function and the call both are ambiguous in the match. Can you match the call sequence? Or explicitly the local label and then the call.

[majnemer]

lib/CodeGen/TargetInfo.cpp

5578

Period at the end of a sentence.

test/CodeGen/arm-float-helpers.c

32 ↗

(On Diff #108092)

Ditto.

test/CodeGen/complex-math.c

482

Ditto.

[peter.smith]

Thanks both for the comments, I've added the missing punctuation and have expanded the tests so that we anchor the check to the function and check for the operation that will be lowered by the back-end.

[peter.smith]

I've created D35904 to cover adding a test for LLVMs use of the runtime helper functions.

lib/CodeGen/TargetInfo.cpp

void ARMABIInfo::setCCs() {
   // they'd just match what LLVM will infer from the triple.
   llvm::CallingConv::ID abiCC = getABIDefaultCC();
   if (abiCC != getLLVMDefaultCC())
     RuntimeCC = abiCC;
 
   // AAPCS apparently requires runtime support functions to be soft-float, but
   // that's almost certainly for historic reasons (Thumb1 not supporting VFP
   // most likely). It's more convenient for AAPCS16_VFP to be hard-float.
-  switch (getABIKind()) {
-  case APCS:
-  case AAPCS16_VFP:
-    if (abiCC != getLLVMDefaultCC())
+
+  // The Run-time ABI for the ARM Architecture section 4.1.2 requires
+  // AEABI-complying FP helper functions to use the base AAPCS
+  // These AEABI functions are expanded in the ARM llvm backend, all the builtin
+  // support functions emitted by clang such as the _Complex helpers follow the
+  // abiCC.
       BuiltinCC = abiCC;
-    break;
-  case AAPCS:
-  case AAPCS_VFP:
-    BuiltinCC = llvm::CallingConv::ARM_AAPCS;
-    break;
-  }
 }
 
 ABIArgInfo ARMABIInfo::classifyArgumentType(QualType Ty,
                                             bool isVariadic) const {
   // 6.1.2.1 The following argument types are VFP CPRCs:
   //   A single-precision floating-point type (including promoted
   //   half-precision types); A double-precision floating-point type;
   //   A 64-bit or 128-bit containerized vector type; Homogeneous Aggregate

test/CodeGen/complex-math.c

 // RUN: %clang_cc1 %s -O1 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
 // RUN: %clang_cc1 %s -O1 -emit-llvm -triple x86_64-pc-win64 -o - | FileCheck %s --check-prefix=X86
 // RUN: %clang_cc1 %s -O1 -emit-llvm -triple i686-unknown-unknown -o - | FileCheck %s --check-prefix=X86
 // RUN: %clang_cc1 %s -O1 -emit-llvm -triple powerpc-unknown-unknown -o - | FileCheck %s --check-prefix=PPC
-// RUN: %clang_cc1 %s -O1 -emit-llvm -triple armv7-none-linux-gnueabihf -o - | FileCheck %s --check-prefix=ARM
+// RUN %clang_cc1 %s -O1 -emit-llvm -triple armv7-none-linux-gnueabi -o - | FileCheck %s --check-prefix=ARM
+// RUN: %clang_cc1 %s -O1 -emit-llvm -triple armv7-none-linux-gnueabihf -o - | FileCheck %s --check-prefix=ARMHF
 // RUN: %clang_cc1 %s -O1 -emit-llvm -triple thumbv7k-apple-watchos2.0 -o - -target-abi aapcs16 | FileCheck %s --check-prefix=ARM7K
 
 float _Complex add_float_rr(float a, float b) {
   // X86-LABEL: @add_float_rr(
   // X86: fadd
   // X86-NOT: fadd
   // X86: ret
   return a + b;
_Bool ne_float_cc(float _Complex a, float _Complex b) {
   // X86: fcmp une
   // X86: or i1
   // X86: ret
   return a != b;
 }
 
 // Check that the libcall will obtain proper calling convention on ARM
 _Complex double foo(_Complex double a, _Complex double b) {
+  // These functions are not defined as floating point helper functions in
+  // Run-time ABI for the ARM architecture document so they must not always
+  // use the base AAPCS
+
   // ARM-LABEL: @foo(
-  // ARM: call arm_aapcscc { double, double } @__muldc3
+  // ARM: call void { double, double } @__muldc3
+
+  // ARMHF-LABEL: @foo(
+  // ARMHF: call { double, double } @__muldc3
 
   // ARM7K-LABEL: @foo(
   // ARM7K: call { double, double } @__muldc3
   return a*b;
 }