* [RFC PATCH] i386: Enable _BitInt support on ia32
@ 2024-02-10 10:19 Jakub Jelinek
2024-02-10 11:06 ` Jakub Jelinek
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2024-02-10 10:19 UTC (permalink / raw)
To: Uros Bizjak, Jan Hubicka, H.J. Lu, Joseph S. Myers; +Cc: gcc-patches
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.
--- 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;
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC PATCH] i386: Enable _BitInt support on ia32
2024-02-10 10:19 [RFC PATCH] i386: Enable _BitInt support on ia32 Jakub Jelinek
@ 2024-02-10 11:06 ` Jakub Jelinek
0 siblings, 0 replies; 2+ messages in thread
From: Jakub Jelinek @ 2024-02-10 11:06 UTC (permalink / raw)
To: Uros Bizjak, Jan Hubicka, H.J. Lu, Joseph S. Myers, gcc-patches
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-02-10 11:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-10 10:19 [RFC PATCH] i386: Enable _BitInt support on ia32 Jakub Jelinek
2024-02-10 11:06 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).