This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by peter.smith on Jul 18 2017, 3:32 AM.

Details

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:

Diff Detail

Repository
rL LLVM

Event Timeline

peter.smith created this revision.Jul 18 2017, 3:32 AM
compnerd requested changes to this revision.Jul 18 2017, 7:08 PM

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).

This revision now requires changes to proceed.Jul 18 2017, 7:08 PM

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 edited edge metadata.

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.

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 added inline comments.
lib/CodeGen/TargetInfo.cpp
5625 ↗(On Diff #108092)

Period at the end of a sentence.

test/CodeGen/arm-float-helpers.c
32 ↗(On Diff #108092)

Ditto.

test/CodeGen/complex-math.c
482 ↗(On Diff #108092)

Ditto.

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.

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

compnerd accepted this revision.Jul 26 2017, 8:02 PM
This revision is now accepted and ready to land.Jul 26 2017, 8:02 PM
This revision was automatically updated to reflect the committed changes.