https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117584
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |linkw at gcc dot gnu.org,
| |segher at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As mentioned on IRC, once the psABI change is figured out, little-endian
support will be easiest, but some work will need to be done on the libgcc side,
currently the dfp <-> _BitInt conversion functions are written only for BID,
not for DPD, although the DPD ones could be fairly similar, just with
encoding/decoding the format differently.
The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays). Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).
As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).
If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.
