https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #58 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (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). > 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.
