https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #48 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 24.05.2023 um 16:18 schrieb jakub at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 > > --- Comment #47 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > But then the pass effectively has to do lifetime analysis of the _BitInt(N) > for > N > 128 etc. SSA_NAMEs and perform the partitioning of those SSA_NAMEs into > VAR_DECLs/PARM_DECLs/RESULT_DECLs, so that we don't blow away the local stack; > perhaps as you wrote with some local subgraphs turned into a loop which will > handle multiple operations together instead of just one operation per loop. > Or just use different VAR_DECLs but stick in clobbers where they will be dead > and hope out of ssa can merge those. > Anyway, more work than I hoped. > Though, perhaps it can be also done incrementally, with bare minimum first and > improvements later. Sure, this is just what I think users will expect. We don’t have the high level infrastructure to do this afterwards such as loop fusion and variable contraction (well, in theory graphite can do it but even there we lack actual transform bits).
