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.
