https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > If I read it correctly, for a path that enters the loop and later leaves > it (where threading is desirable since we skip the whole loop) the logic > above will still return true (after finishing the whole walk which seems > like a waste). Perhaps Richi can comment here, since this is his code? > > This may trigger more often at -Os since we limit loop header copying. Interesting. We have PR102906 which is a code size increase at -Os on ARM for the same commit. I wonder if it's related. > > And indeed, fixing profile updating would be nice. Why the updating > code is not reused across different threaders? (I wrote several thread > updating functions for varioius threaders introduced & remoed in the > past and I wonder why we need to keep reinventing it) This all predates me. I don't know. For the record, both threaders use completely different BB copiers and update mechanisms. It could be they're sufficiently different that reusing it is unfeasible ??.
