[PATCH] D38050: [ARM] Use correct calling convention for libm.

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D38050