https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #44 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 24 May 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Attachment #55141|0 |1 > is obsolete| | > > --- Comment #43 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Created attachment 55148 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55148&action=edit > gcc14-bitint-wip.patch > > Another update. This version can emit _BitInt(N) values in non-automatic > variable initializers, handles passing/returning _BitInt(N) and for N <= 64 > (i.e. what fits into a single limb) from what I can see handling it in GIMPLE > passes and and even expansion/RTL seems to work. > Now, as discussed earlier, for N > GET_MODE_PRECISION (limb_mode) I think we > want to lower it in some pass in between IPA and vectorization. For N which > fits into DImode if limb is 32-bit (currently no target does that as we have > just x86-64 support) or which fits into TImode for 64-bit if TImode is > supported, I guess we want to map arithmetics > to TImode arithmetics, for say 2-4x larger emit code for arithmetics (except > perhaps multiplication/division) inline as straight line code and for even > larger as loops. > In the last case, a question is if we could use e.g. TARGET_MEM_REF for the > variable offset in those loops on the vars even when they aren't > TREE_ADDRESSABLE (but would force them into memory during expansion). Note you should use TARGET_MEM_REF only when it describes the actual addressing mode you want to use. Otherwise just synthesize ARRAY_REFs like ARRAY_REF <VIEW_CONVERT_EXPR (limb[]) <limbs>, index> with an appropriate VLA libm[] array type. I'd do the lowering right before pass_complete_unrolli and generally emit loopy form (another pass placement required in the -Og pipeline).
