[Bug target/113837] New: Zeroing unused bits in _BitInt can improve codegen

[Bug target/113837] New: Zeroing unused bits in _BitInt can improve codegen

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

            Bug ID: 113837
           Summary: Zeroing unused bits in _BitInt can improve codegen
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: crazylht at gmail dot com
  Target Milestone: ---
            Target: x86-64

I opened this x86-64 psABI issue:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/16

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ugh no, please don't.
This is significant ABI change.
First of all, zeroing even for signed _BitInt is very weird, sign extension for
that case is more natural, but when _BitInt doesn't have any unspecified bits,
everything that computes them will need to compute even the extra bits.  That
is not the case in the current code.

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
OT, what is the state of the ia32 _BitInt ABI?  I'd really like to enable it in
GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> OT, what is the state of the ia32 _BitInt ABI?  I'd really like to enable it
> in GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).

I think we should leave ia32 alone.  x32 uses the same psABI as x86-64.

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > OT, what is the state of the ia32 _BitInt ABI?  I'd really like to enable it
> > in GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).
> 
> I think we should leave ia32 alone.

You mean never support C23 on it?

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Ugh no, please don't.
> This is significant ABI change.
> First of all, zeroing even for signed _BitInt is very weird, sign extension
> for that case is more natural, but when _BitInt doesn't have any unspecified
> bits, everything that computes them will need to compute even the extra
> bits.  That is not the case in the current code.

Can we compare zeroing and undefined codegen of unused bits for storing
signed _BitInt?

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Jakub Jelinek from comment #2)
> > > OT, what is the state of the ia32 _BitInt ABI?  I'd really like to enable it
> > > in GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).
> > 
> > I think we should leave ia32 alone.
> 
> You mean never support C23 on it?

Then implement whatever appropriate in GCC and make it the de facto ABI.

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #5)
> (In reply to Jakub Jelinek from comment #1)
> > Ugh no, please don't.
> > This is significant ABI change.
> > First of all, zeroing even for signed _BitInt is very weird, sign extension
> > for that case is more natural, but when _BitInt doesn't have any unspecified
> > bits, everything that computes them will need to compute even the extra
> > bits.  That is not the case in the current code.
> 
> Can we compare zeroing and undefined codegen of unused bits for storing
> signed _BitInt?

Not easily, the bitint_info::extended support isn't there yet (as no target
needed it so far).  See also the discussions about it on IRC and aarch64
_BitInt support thread (aarch64 wants to have the extra bits unspecified, but
arm 32 extended).

> Then implement whatever appropriate in GCC and make it the de facto ABI.

So what's wrong with
https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5
?  Has it been discussed, or is i386-ABI dead?
I'd probably go with 32-bit limbs for _BitInt(65) and higher instead of 64-bit,
but under the hood that is how it will be implemented no matter what the ABI
says,
whether it is 32-bit limbs or 64-bit limbs only affects a) the alignment b) how
much is wasted in case of say _BitInt(65) or _BitInt(129) etc. and what the
sizeof is.
Even if limbs are 64-bit, the question is about alignment, ia32 has 32-bit
alignment for long long and double at least when used inside of structs, so it
would be weird to have different alignment from struct { limb l1, l2; } and
similar.

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, I guess we should have some RTL optimization (possibly backend combiner
pattern)
to be able to optimize stuff like
        sall    $7, y(%rip), %eax
        sall    $7, %edi
        cmpl    %eax, %edi
to xorl %edi, y(%rip), %eax; testl $0x1ffffff, %edx
or similar (and similarly without APX).

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Jakub Jelinek from comment #1)
> > > Ugh no, please don't.
> > > This is significant ABI change.
> > > First of all, zeroing even for signed _BitInt is very weird, sign extension
> > > for that case is more natural, but when _BitInt doesn't have any unspecified
> > > bits, everything that computes them will need to compute even the extra
> > > bits.  That is not the case in the current code.
> > 
> > Can we compare zeroing and undefined codegen of unused bits for storing
> > signed _BitInt?
> 
> Not easily, the bitint_info::extended support isn't there yet (as no target
> needed it so far).  See also the discussions about it on IRC and aarch64
> _BitInt support thread (aarch64 wants to have the extra bits unspecified,
> but arm 32 extended).
> 
> > Then implement whatever appropriate in GCC and make it the de facto ABI.
> 
> So what's wrong with
> https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5
> ?  Has it been discussed, or is i386-ABI dead?

i386 psABI is not actively maintained.

> I'd probably go with 32-bit limbs for _BitInt(65) and higher instead of
> 64-bit,
> but under the hood that is how it will be implemented no matter what the ABI
> says,
> whether it is 32-bit limbs or 64-bit limbs only affects a) the alignment b)
> how much is wasted in case of say _BitInt(65) or _BitInt(129) etc. and what
> the sizeof is.
> Even if limbs are 64-bit, the question is about alignment, ia32 has 32-bit
> alignment for long long and double at least when used inside of structs, so
> it would be weird to have different alignment from struct { limb l1, l2; }
> and similar.

Just implement what is the appropriate in GCC.  We will document it.