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

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

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

--- Comment #59 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #58)
> (In reply to Richard Biener from comment #57)
> > (In reply to Jakub Jelinek from comment #56)
> > > Created attachment 55244 [details]
> > > gcc14-bitint-wip-inc.patch
> > > 
> > > Incremental patch on top of the above patch.
> > > 
> > > I've tried to make some progress and implement the simplest large _BitInt
> > > cases,
> > > &/|/^/~, but ran into a problem there, both BIT_FIELD_REF and
> > > BIT_INSERT_EXPR disallow
> > > operating on non-mode precisions, while for _BitInt I think it would be
> > > really useful
> > > to use them on the large/huge _BitInts (which I will force into memory
> > > during expansion most likely).  Sure, for huge _BitInts, what is handled in
> > > the loop will use either
> > > ARRAY_REF on VIEW_CONVERT_EXPR for operands or TARGET_MEM_REFs on VAR_DECLs
> > > for the results in the loop, but even for those there is the partial most
> > > significant limb in some cases that needs to be handled separately.
> > > 
> > > So, do you think it is ok to make an exception for
> > > BIT_FIELD_REF/BIT_INSERT_EXPR and
> > > allow them on non-mode precision BITINT_TYPEs (the incremental patch enables
> > > that) plus
> > > handle it during the expansion?
> > 
> > The incremental patch doesn't implement the expansion part, right?  The
> 
> Not yet.
> 
> > problem is that BIT_* are specified to work on the in-memory representation
> > and a non-mode precision entity doesn't have this specified - you'd have
> > to extend / shift that to some mode to be able to store it.
> 
> One thing is that the checking and expansion constraints preclude using it
> even on
> full limbs of a _BitInt which has precision in multiples of limb precision.
> Say _BitInt(192) has on x86-64 3 64-bit limbs, but the type necessarily has
> BLKmode,
> because there are no 192-bit modes.
> If we allowed BIT_FIELD_REF/BIT_INSERT_EXPR on non-type_has_mode_precision_p
> BITINT_TYPEs, perhaps we could restrict it to the cases we really need and
> which can be easily implemented.  That is, they'd need to extract or insert
> bits within the same single limb, making it effectively operate on mode
> precision of the limb for all the limbs other than the most significant
> partial one if any, and in the case of the most significant one it could
> either ignore the padding bits above it or sign/zero extend
> into the padding bits when touching the MSB bit (depending on if target says
> those bits are well defined or undefined).

Oh, so BITINT_TYPE is INTEGRAL_TYPE_P but not INTEGER_TYPE (I think we
don't have any BLKmode integer types?).  I think the intent was to
restrict the operation on actual mode entities, BLKmode means memory
where it isn't necessary to restrict things.  So you could add
a BLKmode exception here (but then for _BitInt<63> you will likely
get DImode?)

Can't you use a MEM_REF to extract limb-size INTEGER_TYPE from the
_BitInt<> and then operate on those with BIT_FIELD_REF and BIT_INSERT_EXPR?
Of course when the whole _BitInt<> is a SSA name MEM_REF won't work
(but when you use ARRAY_REF/VIEW_CONVERT the same holds true)

> > Improving code-gen for add-with carry would be indeed nice, I'm not sure
> > we need the user-visible builtins though, matching the open-coded variants
> > to appropriate IFNs would work.  But can the _OVERFLOW variants not be
> > used here, at least for unsigned?
> 
> Yeah, just noticed the clang builtins are badly designed, see PR79173 for
> that,
> so will try to introduce a new ifns and pattern detect them somewhere.