]> git.ipfire.org Git - thirdparty/gcc.git/commit
i386: Enable _BitInt support on ia32
authorJakub Jelinek <jakub@redhat.com>
Mon, 26 Feb 2024 10:12:39 +0000 (11:12 +0100)
committerJakub Jelinek <jakub@redhat.com>
Mon, 26 Feb 2024 10:12:39 +0000 (11:12 +0100)
commitf12697f3298566412386e5d70dc48a431e09b75f
treeba5144a9e8b2c66a00b38bd2309c993dff2a3e16
parenta25d7d1385087e0f43574064db45f1bc7d52f400
i386: Enable _BitInt support on ia32

Given the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837#c9
comment, the following patch just attempts to implement what I think
is best for ia32.

Compared to https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 ,
like that patch for _BitInt(64) or smaller it uses the smallest containing
{,un}signed {char,short,int,long long} for passing/returning and
layout of variables including in structures for alignment/size, with any
extra bits unspecified.
Unlike the above proposal, for larger _BitInt (i.e. _BitInt(65)+), it uses
passing/returning/layout/alignment of structure containing minimum needed
number of 32-bit limbs, again with the extra bits unspecified.
This is because most operations (except copy or bitwise ops) on _BitInts
aren't really vectorizable and will be under the hood implemented in loops
over 32-bit limbs anyway (using 64-bit limbs under the hood would mean
often using library implementation for the basic operations) and because
ia32 doesn't align even long long/double in structures to 64-bit I think
it is better to just use 32-bit alignment for that.  And I don't see
a reason to waste 32-bit bits say for _BitInt(224) or _BitInt(288) on ia32.

So, effectively it is like the x86-64 _BitInt ABI with everything divided by
2, the only exception is that in x86-64 psABI _BitInt(128) is said to be
already a structure of 2 limbs, which happens to be passed mostly the same
as __int128 (except for alignment).

2024-02-26  Jakub Jelinek  <jakub@redhat.com>

* config/i386/i386.cc (ix86_bitint_type_info): Add support for
!TARGET_64BIT.
gcc/config/i386/i386.cc