Open Vexu opened 1 year ago
Worth mentioning that i128 on clang x86-64 does not respect the SysV ABI either (https://github.com/rust-lang/rust/issues/54341#issuecomment-1064729606). LLVM lowers compiler-rt calls to that bad ABI, so it's the same problem I think. See https://github.com/ziglang/zig/pull/12145#issuecomment-1186358666
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?
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
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-bittu_int
LLVM uses for compiler-rt.Possible solutions are:
i128
on targets that don't support__int128
, add specialc_tu_int
type that matches compiler-rt'stu_int
i128
match_BitInt(128)
(and make 1-128 bit integers C ABI compatible) and move the compiler-rt call lowering to our own LLVM backendi128
always match compiler-rt'stu_int
, do not support_BitInt