Alignment of __int128 on ILP32

[xypron]

The alignment of __int128 is only defined on LP64 but not on ILP32.

[jrtc27]

Like other 32-bit architectures, there is no __int128 available on RV32

[kito-cheng]

The major reason is what @jrtc27 said, more detail: currently GCC and clang/LLVM are not support __int128 on ILP32, that's implementable on ILP32, but there is some ... technical issue to support that on GCC side, and no 32 bit in GCC has supported __int128, so we don't support that on both compiler now.

[xypron]

Standardization should not be an afterthought but should be done before implementation. So it is good to define the alignment of __int128 before it is implemented in 32bit tools.

[jrtc27]

Our policy (see policy.md) is:

• Changes requiring compiler changes
  • Require an open source PoC implementation for GCC or LLVM, either as a patch on the mailing list/Phabricator as appropriate or in a GitHub fork
  • Require at least one GCC developer AND one LLVM developer to approve

If people want __int128 to exist on RV32 then we can standardise it, but they need to want it and be willing to support it in toolchains. We're not going to add things to the specification that aren't going to be implemented or aren't wanted.

[ptomsich]

__int128 will still need to be standardised for ILP32, if ILP32 is used with RV64 (e.g. to have more cache-efficient userspace binaries on a 64bit kernel).

[workingjubilee]

It is probably best if whatever ABI is specified for _BitInt(128) for ILP32 would be tolerable if it were also interpreted as the ABI of __int128 in the ILP32 case, per my reasoning in #300 (comment). The introduction of such a bit-precise way of saying "a 128-bit integer" would make adding it to the smaller data model an "obvious" extension.

[pellico]

Having a defined ABI for __int128 would improve the interface between Rust and C