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

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In https://reviews.llvm.org/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.


Repository:
  rL LLVM

https://reviews.llvm.org/D38050