https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #7 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> --- Right, I've trimmed too much context from my message. This performance regression starts with r239219 which adds a cost model to the threader which relies on frequency information (arguably this is a bad cost model for threading, as at a switch statement you might expect multiple cold edges, and still want to thread the switch, but that's a separate discussion). The threader does a bad job of updating frequency information when it creates new paths, with the effect that the edges we'd want to thread in this test case appear to be cold. The new cost model from r239219 sees the cold edges, and rejects the threading opportunity. The message I was replying to above had said: > Hmm, this is interesting. The patch should have "fixed" the previous > degradation by making the profile correct (backward threader still doe not > update it, but because most threading now happens early and profile is built > afterwards this should be less of issue). I am now looking into the profile > update issues and will try to check why coremarks degrade again. The answer to which is that the early-threader has hard-coded that it is compiling for size, which causes most backward threading to be rejected, so wouldn't fix this issue. However, if we were to use optimize_bb_for_size_p in pass_early_thread_jumps::execute rather than just passing false then the early threader would have resolved this issue (as the profile information is not used to decide if the edge should be optimised for speed).
