[Compiler-rt] Implement AEABI Unaligned Read/Write Helpers in compiler-rt #167913
Conversation
…r-rt This patch adds implementations for the __aeabi_uread and __aeabi_uwrite helper functions to compiler-rt..
| // See https://llvm.org/LICENSE.txt for license information. | ||
| // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
| // | ||
| //===-----------------------------------------------------------------------------===// |
There was a problem hiding this comment.
Probably a good idea to link to the document defining these functions.
https://github.com/ARM-software/abi-aa/blob/main/rtabi32/rtabi32.rst#unaligned-memory-access
| char v[4]; | ||
| } v4; | ||
|
|
||
| int __aeabi_uread4(void *p) { |
There was a problem hiding this comment.
I was going to say that surely the read functions should take a const void *, but in RTABI, they don't! I suppose because nobody ever calls these functions from C, so the C prototype isn't really important, only the machine-level PCS that it translates into.
| extern long long __aeabi_uread8(void *); | ||
| extern long long __aeabi_uwrite8(long long, void *); | ||
|
|
||
| #define lenof(x) (sizeof((x)) / sizeof(*(x))) |
There was a problem hiding this comment.
It's 2025, so we can use _Countof for this! \o/
| long long target8; | ||
| int target4; | ||
| const char source[] = "abcdefghijklmno"; | ||
| static char dest1[lenof(source)], dest2[lenof(source)]; |
There was a problem hiding this comment.
Using static is optional. It’s used here mainly to improve reproducibility — since it provides a stable address from which we can repeatably test unaligned writes.
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
🐧 Linux x64 Test Results
|
…compiler-rt Apply clang-format to address style issues in the previous patch.
efriedma-quic
left a comment
efriedma-quic
left a comment
There was a problem hiding this comment.
LLVM currently doesn't generate calls to these functions. From what I recall, my team did some internal testing of these functions at one point, and we found it basically doesn't make sense to call the 4-byte versions; on cores that still care about misaligned accesses, calls are expensive, so the tradeoff isn't really worth it for normal code.
Do you have some plan to use these functions?
|
|
||
| typedef struct { | ||
| char v[4]; | ||
| } v4; |
There was a problem hiding this comment.
Technically, to avoid breaking TBAA rules, this needs to be __attribute__((__may_alias__)). Not sure if it's likely to matter in practice.
Yes, we are currently working on enabling LLVM to emit these functions. I don’t have the patch ready right now, but I’m working on it and will send it soon. These helpers are not intended for performance-oriented code paths—indeed, the call overhead can make them unsuitable for that. These functions are planned to be emitted only for size-optimised code paths (-Os/-Oz) and also when -mno-unaligned-access (or equivalent) is used. Without these helpers, LLVM would need to inline byte wise sequences , which can increases code size, especially at -Os/-Oz. Using the helper functions allows to retain correctness while avoiding that code-size growth. We haven’t benchmarked this yet, but we do expect some code-size savings in real workloads. Even though many modern Arm cores handle unaligned accesses natively, there are still deployments—particularly in embedded and legacy environments—where unaligned support is limited or intentionally disabled. The AEABI helpers can give a mechanism to handle these cases. Another motivation is ABI and ecosystem consistency. GCC-based toolchains already provide these AEABI helpers, so supporting them in compiler-rt ensures parity and avoids accidental dependencies on libgcc when LLVM begins emitting these calls. Happy to hear any thoughts or concerns. Feedback on additional use-cases or scenarios we should consider would be very welcome. |
|
Okay, that's fine. I suspect the performance penalty is too large at -Os; maybe it's okay at -Oz. |
5 participants
This patch adds implementations for the __aeabi_uread and __aeabi_uwrite helper functions to compiler-rt.
Without these helpers, LLVM would need to inline byte wise sequences , which can increases code size, especially at -Os/-Oz. Using the helper functions allows to retain correctness while avoiding the code-size growth.
GCC-based toolchains already provide these AEABI helpers, so supporting them in compiler-rt ensures parity and avoids accidental dependencies on libgcc when LLVM begins emitting these calls.