r291677 breaks AEABI comparison function on hard FP targets

[asl]

Bugzilla Link	34167
Resolution	FIXED
Resolved on	Aug 23, 2017 14:39
Version	unspecified
OS	All
Blocks	#32377 #33196
CC	@asl,@compnerd,@zmodem

Extended Description

r291677 changes the calling convention of compiler builtin function on hard FP targets. However, it seems that not all AEABI builtins were updated for this new CC.

Consider __aeabi_fcmpeq. It received the arguments, as it should,
using the AAPCS calling convention in r0/r1, then __aeabi_fcmpeq directly calls __eqsf2. But on HF target we'll end with __eqsf2 that expects to receive arguments in s0/s1 and latter does:

+#if defined(COMPILER_RT_ARMHF_TARGET)

• vmov r0, s0
• vmov r1, s1
  +#endif

trashing the contents of r0/r1 with whatever values were in s0/s1.

This affects both ToT, 4.0 and 5.0

[compnerd]

IIUC, this is due to the fact that the AAPCS VFP variant permits the callee to use r0-r3, s0-s3, and ip as scratch and makes the registers caller saved.

I believe that the functions impacted are:
__aeabi_dcmp{eq,lt,le,ge,gt}, calling __{eq,lt,le,ge,gt}df2
__aeabi_fcmp{eq,lt,le,ge,gt}, calling __{eq,lt,le,ge,gt}sf2
__aeabi_fcmpum, calling __unordsf2

and in particular around the internal call which may use the registers.

[asl]

IIUC, this is due to the fact that the AAPCS VFP variant permits the callee to use
r0-r3, s0-s3, and ip as scratch and makes the registers caller saved.
I don't think so. The s0 / s1 registers are just not contain the argument values on the function call :)

[llvmbot]

Addressed in https://reviews.llvm.org/D36675

[zmodem]

Addressed in https://reviews.llvm.org/D36675

Any progress on this?

[asl]

Patch landed in r311555. Please merge into release branch.

[zmodem]

Patch landed in r311555. Please merge into release branch.

Merged in r311606.