diff mbox series

[RFC] i386: Enable _BitInt support on ia32

Message ID ZcdNpLWC4B5JMuqM@tucnak
State Unresolved
Headers
Series [RFC] i386: Enable _BitInt support on ia32 |

Checks

Context Check Description
snail/gcc-patch-check warning Git am fail log

Commit Message

Jakub Jelinek Feb. 10, 2024, 10:19 a.m. UTC 
  Hi!

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).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

There are still 2 regressions:
+FAIL: gcc.dg/pr113693.c  at line 13 (test for warnings, line )
+FAIL: gcc.dg/torture/bitint-24.c   -O0  execution test
+FAIL: gcc.dg/torture/bitint-24.c   -O2  execution test
For pr113693.c I think we'll need to do something with the test, either
make it x86_64 specific, add say -msse2 option for ia32, move to
gcc.dg/vect/
And bitint-24.c case seems to be miscompilation of __floatbitintxf
when built with -O2 -m32, it works fine when compiled with -O0 -m32.
Will address that next week.

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

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


	Jakub

Comments

Jakub Jelinek Feb. 10, 2024, 11:06 a.m. UTC | #1 
On Sat, Feb 10, 2024 at 11:19:16AM +0100, Jakub Jelinek wrote:
> And bitint-24.c case seems to be miscompilation of __floatbitintxf
> when built with -O2 -m32, it works fine when compiled with -O0 -m32.
> Will address that next week.

Ugh, -O2 -m32 -march=i686 works fine, -O2 -m32 -march=i686 -mtune=generic
misbehaves, -O2 -m32 -march=i686 -mtune=generic -fno-ivopts works fine.
Will not be fun to debug, the function is large.

	Jakub
diff mbox series

Patch

--- gcc/config/i386/i386.cc.jj	2024-02-09 11:02:15.193830702 +0100
+++ gcc/config/i386/i386.cc	2024-02-09 16:30:28.568240299 +0100
@@ -25757,13 +25757,11 @@  ix86_get_excess_precision (enum excess_p
 bool
 ix86_bitint_type_info (int n, struct bitint_info *info)
 {
-  if (!TARGET_64BIT)
-    return false;
   if (n <= 8)
     info->limb_mode = QImode;
   else if (n <= 16)
     info->limb_mode = HImode;
-  else if (n <= 32)
+  else if (n <= 32 || (!TARGET_64BIT && n > 64))
     info->limb_mode = SImode;
   else
     info->limb_mode = DImode;