Repository navigation
i128 and C ABI #13263
Description
On 64-bit targets i128 maps directly to __int128 but on targets that don't support it (seeming all <64-bit targets excluding wasm) that cannot be done. A C compiler would give you an error like __int128 is not supported on this target but we can't do that since LLVM's compiler-rt ABI requires 128-bit ints for functions like __divti3.
One option would be to make it match C23's _BitInt(128) but that is not always compatible with the 128-bit tu_int LLVM uses for compiler-rt.
Possible solutions are:
- forbid
i128on targets that don't support__int128, add specialc_tu_inttype that matches compiler-rt'stu_int - make
i128match_BitInt(128)(and make 1-128 bit integers C ABI compatible) and move the compiler-rt call lowering to our own LLVM backend - make
i128always match compiler-rt'stu_int, do not support_BitInt
Activity
topolarity commentedon Oct 22, 2022
Worth mentioning that i128 on clang x86-64 does not respect the SysV ABI either (rust-lang/rust#54341 (comment)). LLVM lowers compiler-rt calls to that bad ABI, so it's the same problem I think. See #12145 (comment)
I'm not sure whether it's easier to try to fix LLVM to respect the ABI (two revisions have stalled so far), or to anticipate where it might lower syscalls and dodge them in advance.
In theory, optimization passes mean that the latter approach will never work completely, right?
topolarity commentedon Oct 22, 2022
This one is not i128-specific, but there are also platforms where libgcc uses a special calling convention per-function: https://gcc.gnu.org/wiki/avr-gcc#Exceptions_to_the_Calling_Convention
I'm not sure whether Clang/LLVM does the same on AVR or not