i128 and C ABI

[Vexu]

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 i128 on targets that don't support __int128, add special c_tu_int type that matches compiler-rt's tu_int
• make i128 match _BitInt(128) (and make 1-128 bit integers C ABI compatible) and move the compiler-rt call lowering to our own LLVM backend
• make i128 always match compiler-rt's tu_int, do not support _BitInt

[topolarity]

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?

[topolarity]

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