[Bug c/102989] Implement C2x's n2763 (_BitInt)

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55240|0                           |1
        is obsolete|                            |
  Attachment #55244|0                           |1
        is obsolete|                            |

--- Comment #64 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 55327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55327&action=edit
gcc14-bitint-wip.patch

Some further progress.  I found that out of SSA coalescing coalesces only a
very small subset of SSA_NAMEs, for _BitInt we need to coalesce significantly
more, try to use as few VAR_DECL arrays as possible so that we don't blow away
stack sizes.

So, I'm trying to find the large/huge _BitInt SSA_NAMEs, quickly find out some
which won't be needed as they could be handled inside of a single loop (to be
improved later) and then doing aggressive coalesing on those and eventually map
those SSA_NAMEs to VAR_DECLs.

On
void
foo (_BitInt(192) *x, _BitInt(192) *y, _BitInt(135) *z, _BitInt(135) *w)
{
  _BitInt(192) a;
  if (x[0] == y[0])
    a = 123wb;
  else if (x[0] == y[1])
    a = y[2];
  else if (x[0] == y[2])
    a = y[3];
  else
    a = 0wb;
  x[4] = a;
  x[5] = x[0] == y[0] ? x[6] : x[0] == y[1] ? x[7] : x[0] == y[2] ? x[8] :
x[9];
  x[0] &= y[0];
  x[1] |= y[1];
  x[2] ^= y[2];
  x[3] = ~y[3];
  z[0] &= w[0];
  z[1] |= w[1];
  z[2] ^= w[2];
  z[3] = ~w[3];
}
I'm seeing weird results though, e.g.
  _1 = *x_32(D);
  _2 = *y_33(D);
  if (_1 == _2)
but
After Coalescing:

Partition map

Partition 0 (_1 - 1 2 3 4 5 6 7 8 10 11 13 14 16 29 30 34 35 37 38 39 40 )
Partition 1 (_9 - 9 )
Partition 2 (_12 - 12 )
Partition 3 (_15 - 15 )
Partition 4 (_17 - 17 )
Partition 5 (_18 - 18 19 21 22 24 25 27 )
Partition 6 (_20 - 20 )
Partition 7 (_23 - 23 )
Partition 8 (_26 - 26 )
Partition 9 (_28 - 28 )
Partition 10 (x_32(D) - 32 )
Partition 11 (y_33(D) - 33 )
Partition 12 (z_46(D) - 46 )
Partition 13 (w_47(D) - 47 )

Obviously, _1 and _2 need to conflict because they have overlapping live ranges
(sure, later on loads from memory should be handled in a smarter way, no need
to copy it into another array if at the point of a single use within the same
bb (at least) the memory couldn't be clobbered yet).