https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #40) > Created attachment 55094 [details] > gcc14-bitint-wip.patch > > So, on IRC we've agreed with Richi that given the limits we have in the > compiler > (what wide_int/widest_int can represent at most without making the types have > optional arbitrary length indirect payload, what INTEGER_CST can handle > (right > now 255 64-bit limbs) and TYPE_PRECISION limitation (max 65535 precision)) > it would be best to first try to implement _BitInt support with small > BITINT_MAXWIDTH (in particular, what fits into wide_int, which is e.g. on > x86_64 > 575 bits) and only when the implementation of that is complete, attempt to > lift > up some of the limits (start with the wide_int/widest_int one, INTEGER_CST > could > be handled by bumping the 2 counters from 8-bit to 16-bit and killing the > cache, > with that we'd be at 65535 as BITINT_MAXWIDTH and whether we'd want to grow > it > further is a question). > > This patch implements some WIP, as the testcases show, it can already do > something, but doesn't have any of the argument/return value passing code > implemented, nor middle-end needed changes (promoting as much as possible to > small INTEGER_TYPEs early for small BITINT_TYPEs and adding a lowering pass > which will turn the larger ones into loops etc.). Also, wb/uwb constants > aren't > really done yet. Another idea is to have a large BITINT_MAXWIDTH (up to what TYPE_PRECISION supports) but restrict constant folding to the cases we can represent in INTEGER_CST. For the cases where the language requires constant evaluation we'd then sorry (). I think we should be able to handle all-ones encoded and since constant initializers are restricted it should handle most practical cases already.
