[compiler-rt] Fix tests of __aeabi_(idivmod|uidivmod|uldivmod) to support big endian

[vhscampos]

This patch makes these functions' tests work in big endian mode:

• __aeabi_idivmod.
• __aeabi_uidivmod.
• __aeabi_uldivmod.

The three functions return a struct containing two fields, quotient and remainder, via value in regs calling convention. They differ in the integer type of each field.

In the tests of the first two, a 64-bit integer is used as the return type of the call. And as consequence of the ABI rules for structs (Composite Types), the quotient resides in r0 and the remainder in r1 regardless of endianness. So, in order to access each component from the 64-bit integer in the caller code, care must be taken to access the correct bits as they do depend on endianness in this case.

In the test of the third one, the caller code has inline assembly to access the components. This assembly code assumed little endian, so it had to be made flexible for big endian as well.

_YUGA_BIG_ENDIAN is defined in int_endianness.h. It's a macro internal to compiler-rt that's in theory compatible with more toolchains than gcc and clang.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[statham-arm]

Can you explain some more in the commit message, please? All it says is that it's "making things work", but not what was wrong with them, or why, or what values go where.

The 32-bit integer division functions __aeabi_idivmod and __aeabi_uidivmod shouldn't change their ABI depending on endianness. They're defined to deliver the quotient in r0 and the remainder in r1, whether they're big- or little-endian. (source) So why is this change swapping the result registers around? Which one do you think is which? Are they coming back from __divmodsi4 in opposite order, for some reason?

Also, all these changes are conditional on the macro _YUGA_BIG_ENDIAN. What is that? Where's it defined? The ACLE macro name is __ARM_BIG_ENDIAN. Does this other macro indicate a different change to the ABI?

[vhscampos]

From what you have said, the tests are what's wrong, not the implementations. I will make the changes.

The respective tests were failing in big endian, and I interpreted that the implementation had to swap the values according to endianness. We recently had a similar bug somewhere else in compiler-rt where the issue was in fact in the implementation.

The RTABI isn't very clear to me: "The 32-bit integer division functions return the quotient in r0 or both quotient and remainder in {r0, r1}". It doesn't explicitly say "in {r0, r1} respectively", which made me dubious about whether the order changed with endianness or not.

_YUGA_BIG_ENDIAN is defined in int_endianness.h. It's a macro internal to compiler-rt that's in theory compatible with more toolchains than gcc and clang.

[statham-arm]

It doesn't explicitly say "in {r0, r1} respectively",

True – perhaps that could be clarified. But it does say that those functions return (via the __value_in_regs variant PCS) a value of type struct { int quot; int rem; }. That's the part that definitely means the quotient is in the lower-numbered register, because it appears at the start of the struct.

[vhscampos]

Fixed. Thanks for the comments.

[statham-arm]

Ah, now I look at the tests of 32-bit division, I understand!

Yes, this version of the patch makes much more sense, because now I see that the test code is hacking around lack of support for __value_in_regs by pretending that __aeabi_idivmod returns a uint64_t, and then breaks it up into quotient and remainder halves, which needs to be done opposite ways round depending on the endianness of that integer.

I've pressed the approve button, but you might consider adding a comment to explain that, since it might very well not be obvious to the next person reading this code?