[ARM] Use correct calling convention for libm.

[efriedma]

Summary

-mfloat-abi doesn't control the calling convention for compiler-rt: it's built with the compiler, so it can only have one calling convention for a given target. -mfloat-abi does control the calling convention for any function provided by libm: libm is built by the user, so the user should have control over its calling convention. See https://bugs.llvm.org/show_bug.cgi?id=30543 for previous discussion on the subject.

I don't really like the big list, but I'm not sure there's a better way to handle this.

Fixes https://bugs.llvm.org//show_bug.cgi?id=34530.

[compnerd]

lib/Target/ARM/ARMISelLowering.cpp

313

I think that it would be better to have a table and just walk that rather than doing this explicitly.

[peter.smith]

My apologies in advance if I've missed something. If I understand this correctly we are tying the calling convention used for compiler-rt to the triple, but for user code, and with this change for builtins provided by libm) we allow -mfloat-abi to determine the calling convention? I think that this can be simplified, but it does require removing the association between triple and compiler-rt float-abi, which I don't think should be there. I think that the behaviour for targets intending to follow the ABI for the Arm Architecture (i.e. not Apple or Microsoft) should be:

• The aeabi functions described in RTABI chapter 4.1.2 required to use AAPCS should always use ARM_AAPCS.
• A triple with a suffix of HF such as arm-linux-gnueabihf implies ARM_AAPCS_VFP for all other builtins, otherwise ARM_AAPCS is used.
• The -mfloat-abi=hard should override whatever is in the triple for all other builtins. There should be no special treatment for compiler-rt.

We would then not need to maintain a list of builtins with floating point parameters defined outside compiler-rt.

My argument for not giving special treatment to compiler-rt is:

• The HF in the gcc target is a naming convention followed by some but not all distributions, my understanding is that Debian uses it but Red Hat does not, or at least did not.
• The -mfloat-abi overrides the default float-abi for all libraries including libgcc.
• If there is a good, or just legacy, reason to give compiler-rt special treatment, perhaps it should be controllable by an option.

For example I have an arm-linux-gnueabi and arm-linux-gnueabihf linaro toolchains installed. With the source program:

#include <math.h>
/* defined in compiler-rt */
double _Complex ComplexMul(double _Complex c, double _Complex d) {
  return c * d;
}

/* defined in libm */
float SquareRoot(float f) {
  return sqrt(f);
}

With a soft-float gcc, with an extra -I to find the missing gnu/stubs-hard.h that aren't included in the soft-float distribution:

arm-linux-gnueabi-gcc -c t.c -mfloat-abi=hard -I /work/arm-linux-gnueabihf/libc/usr/include

I get both functions called with ARM-AAPCS-VFP

p.s. I note that div[d,s,t]f3.c in compiler-rt calls out to sqrt, would be an interesting test case to make sure that we get right.

[efriedma]

I was working under the assumption the behavior test/CodeGen/Thumb2/intrinsics-cc.ll is testing for is is correct; if it's wrong, I'm happy to change the patch. (I probably should have tested gcc before posting this; looks like clang's current handling of __builtin_powi is different from gcc.)

[compnerd]

@peter.smith the reason that the complexity exists currently is interoperability with gcc. If the triple is not hf, libgcc does not use AAPCS_VFP_CC. This is the source of the problem. Your mapping is correct though:

• RTABI §4.1.2 functions must use AAPCS_VFP
• builtins (excluding RTABI §4.1.2 symbols) use AAPCS_VFP_CC if the target environment is hf, AAPCS_CC otherwise
• all remaining functions are determined based on -mfloat-abi=.

I believe the triple convention differences impact the CC for libgcc on the various targets as well. It just is that it is usually statically linked so people don't realize the difference.

[rengolin]

Do you know what would be cool? A gcc-compatibility checker test... Something that would have the most problematic cases in C and asm files and would be compiled with multiple versions of gcc and clang triples, then compared.

It's probably a very boring job to do, but once created, we wouldn't have to rehash those silly legacy ABI craziness... :(

Who knows, maybe we can even show other people how silly those things are, and they can even fix on their compiler! (nah, just kidding...)

[peter.smith]

In D38050#876969, @compnerd wrote:

@peter.smith the reason that the complexity exists currently is interoperability with gcc. If the triple is not hf, libgcc does not use AAPCS_VFP_CC. This is the source of the problem. Your mapping is correct though:

• RTABI §4.1.2 functions must use AAPCS_VFP
• builtins (excluding RTABI §4.1.2 symbols) use AAPCS_VFP_CC if the target environment is hf, AAPCS_CC otherwise
• all remaining functions are determined based on -mfloat-abi=.

I believe the triple convention differences impact the CC for libgcc on the various targets as well. It just is that it is usually statically linked so people don't realize the difference.

A further complexity is that I lose track of the product of {clang, gcc} * { compiler-rt, libgcc} ...

From what I understand of gcc, the calling convention used (outside of RTABI 4.1.2) is that -mfloat-abi will override the default given in the builtin specs file, there isn't anything special about libgcc. The -mfloat-abi won't change the include and default library paths given by the builtin specs file so if I use -mfloat-abi=hard from an arm-linux-gnueabi-gcc it will select the soft-float libgcc.a and other libraries. With ld.bfd this gives me a link error due to the BuildAttribute clash between the static libraries and my object.

arm-linux-gnueabi/bin/ld: error: /tmp/ccPq8Sq6.o uses VFP register arguments, t.axf does not

So I think clang/llvm is doing something different than gcc here, albeit in gcc if the user does use a different -mfloat-abi from the sysroot they will get an error from the static libraries, interestingly shared-libraries don't have BuildAttributes so there is no checking a shared-library mismatch.

Taking the discussion back to the patch, I think that it is the right thing to do to call builtins in libm with -mfloat-abi, so I've no objections to the patch. I'm not sure that making a special case out of the builtins in compiler-rt/libgcc is the right thing to do but this is probably best handled in a different review; there is a huge amount of emulation logic in clang based on target environment that I don't understand, so I could easily be missing something.

[efriedma]

See https://reviews.llvm.org/D38299; from the discussion here and my testing, it seems like that patch more closely matches what gcc actually does.

[efriedma]

Abandoning in favor of D38299

lib/Target/ARM/ARMISelLowering.cpp

ARMTargetLowering::ARMTargetLowering(const TargetMachine &TM,
   RegInfo = Subtarget->getRegisterInfo();
   Itins = Subtarget->getInstrItineraryData();
 
   setBooleanContents(ZeroOrOneBooleanContent);
   setBooleanVectorContents(ZeroOrNegativeOneBooleanContent);
 
   if (!Subtarget->isTargetDarwin() && !Subtarget->isTargetIOS() &&
       !Subtarget->isTargetWatchOS()) {
+    // Most builtins have their calling convention determined by the
+    // target (they don't vary with -float-abi).
     const auto &E = Subtarget->getTargetTriple().getEnvironment();
 
     bool IsHFTarget = E == Triple::EABIHF || E == Triple::GNUEABIHF ||
                       E == Triple::MuslEABIHF;
     // Windows is a special case.  Technically, we will replace all of the "GNU"
     // calls with calls to MSVCRT if appropriate and adjust the calling
     // convention then.
     IsHFTarget = IsHFTarget || Subtarget->isTargetWindows();
 
     for (int LCID = 0; LCID < RTLIB::UNKNOWN_LIBCALL; ++LCID)
       setLibcallCallingConv(static_cast<RTLIB::Libcall>(LCID),
                             IsHFTarget ? CallingConv::ARM_AAPCS_VFP
                                        : CallingConv::ARM_AAPCS);
+
+    // Builtins provided by libm have their calling convention determined by
+    // -float-abi.
+    bool IsHFMode = TM.Options.FloatABIType == FloatABI::Hard;
+    CallingConv::ID LibmConv = IsHFMode ? CallingConv::ARM_AAPCS_VFP
+                                        : CallingConv::ARM_AAPCS;
+    setLibcallCallingConv(RTLIB::REM_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::REM_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::REM_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::FMA_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::FMA_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::FMA_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::SQRT_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::SQRT_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::SQRT_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG2_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG2_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG2_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG10_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG10_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::LOG10_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::EXP_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::EXP_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::EXP_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::EXP2_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::EXP2_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::EXP2_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::SIN_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::SIN_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::SIN_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::COS_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::COS_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::COS_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::SINCOS_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::SINCOS_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::SINCOS_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::POW_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::POW_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::POW_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::CEIL_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::CEIL_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::CEIL_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::TRUNC_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::TRUNC_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::TRUNC_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::RINT_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::RINT_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::RINT_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::NEARBYINT_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::NEARBYINT_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::NEARBYINT_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::ROUND_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::ROUND_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::ROUND_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::FLOOR_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::FLOOR_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::FLOOR_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::COPYSIGN_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::COPYSIGN_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::COPYSIGN_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::FMIN_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::FMIN_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::FMIN_F128, LibmConv);
+    setLibcallCallingConv(RTLIB::FMAX_F32, LibmConv);
+    setLibcallCallingConv(RTLIB::FMAX_F64, LibmConv);
+    setLibcallCallingConv(RTLIB::FMAX_F128, LibmConv);
   }
 
   if (Subtarget->isTargetMachO()) {
     // Uses VFP for Thumb libfuncs if available.
     if (Subtarget->isThumb() && Subtarget->hasVFP2() &&
         Subtarget->hasARMOps() && !Subtarget->useSoftFloat()) {
       static const struct {
         const RTLIB::Libcall Op;
         const char * const Name;

test/CodeGen/Thumb2/intrinsics-cc.ll

 
 ; RUN: llc -mtriple thumbv7-unknown-none-musleabi -float-abi soft -filetype asm -o - %s | FileCheck %s -check-prefix CHECK-MATCH
 ; RUN: llc -mtriple thumbv7-unknown-none-musleabi -float-abi hard -filetype asm -o - %s | FileCheck %s -check-prefix CHECK-MISMATCH -check-prefix CHECK-TO-SOFT
 ; RUN: llc -mtriple thumbv7-unknown-none-musleabihf -float-abi soft -filetype asm -o - %s | FileCheck %s -check-prefix CHECK-MISMATCH -check-prefix CHECK-TO-HARD
 ; RUN: llc -mtriple thumbv7-unknown-none-musleabihf -float-abi hard -filetype asm -o - %s | FileCheck %s -check-prefix CHECK-MATCH
 
 declare float @llvm.powi.f32(float, i32)
 
-define float @f(float %f, i32 %i) {
+define float @powi_f32(float %f, i32 %i) {
 entry:
   %0 = call float @llvm.powi.f32(float %f, i32 %i)
   ret float %0
 }
 
 ; CHECK-MATCH: b __powisf2
 ; CHECK-MISMATCH: bl __powisf2
 ; CHECK-TO-SOFT: vmov s0, r0
 ; CHECK-TO-HARD: vmov r0, s0
 
 declare double @llvm.powi.f64(double, i32)
 
-define double @g(double %d, i32 %i) {
+define double @powi_f64(double %d, i32 %i) {
 entry:
   %0 = call double @llvm.powi.f64(double %d, i32 %i)
   ret double %0
 }
 
 ; CHECK-MATCH: b __powidf2
 ; CHECK-MISMATCH: bl __powidf2
 ; CHECK-TO-SOFT: vmov d0, r0, r1
 ; CHECK-TO-HARD: vmov r0, r1, d0
 
+declare float @llvm.floor.f32(float)
+
+define float @floor_f32(float %f) {
+entry:
+  %0 = call float @llvm.floor.f32(float %f)
+  ret float %0
+}
+
+; CHECK-MATCH: b floorf
+; CHECK-MISMATCH: b floorf
+
+declare double @llvm.floor.f64(double)
+
+define double @floor_f64(double %d) {
+entry:
+  %0 = call double @llvm.floor.f64(double %d)
+  ret double %0
+}
+
+; CHECK-MATCH: b floor
+; CHECK-MISMATCH: b floor