https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118070
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Each psABI defines the rules, and those can be quite different.
Right now, the target hook is prepared to decide on the modes/alignment used
for small _BitInts, whether the padding bits are unspecified or sign/zero
extended, what the limb mode size, what the limb abi mode/alignment is, what is
the limb ordering.
Right now we have just 3 targets supporting _BitInt, because those are the only
ones with defined psABI and backend implementation.
For _BitInt(N) or unsigned _BitInt(N), the x86_64 rules are:
N <= 64 handled like the smallest of {,un}signed {char,short,int,long} into
which it fits, with the padding bits unspecified.
N > 64, it is like unsigned long limbs[(N + 63) / 64]; (passed as struct
containing that though), little endian ordering of the limbs, again with
padding bits unspecified.
ia32 has it similar except s/64/32/g;s/63/31/g.
AArch64 has N <= 128 handled like the smallest of {,un}signed
{char,short,int,long,__int128} into which it fits, with the padding bits
unspecified.
N > 128 like unsigned __int128 limbs[(N + 127) / 128];, little endian, padding
bits unspecified, though for libgcc purposes the limb is 64-bit (only possible
when the limb ordering matches bit ordering within limbs).
There is also ARM 32-bit psABI but that e.g. requires sign/zero extension of
padding bits, currently the backend not implemented in GCC.
Other targets can define something different.
So, would say big-endian SSO imply just the limbs are byteswapped, or the limb
order is swapped, or both, same limb size and other parameters, something
different?
