https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117888
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 3 Dec 2024, liuhongt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117888 > > --- Comment #3 from Hongtao Liu <liuhongt at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #2) > > The question is how we should define innermost - consider > > > > - loop interchange > > - inlining of a function body with a loop into a loop > > > > the simplest approach might be to flag the innermost loop as written by > > the user in source at CFG build time (when we first record loops) and then > > only ever treat that as "innermost" (for heuristics) but still allow facts > > (a loop->inner) to override this (after interchange, inlining). > > The original motivation was to prevent losing vectorization opportunity after > cunrolli, so let's restrict the size reduction change in cunrolli and define > innermost in cunrolli as by the first time the loop is visited in cunrolli, > loop->inner is empty. That also works I guess.
