http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
--- Comment #10 from Jeffrey A. Law <law at redhat dot com> --- So I've got the base infrastructure in the jump threader to perform this optimization. The outstanding issues specific to the coremark optimization: 1. GCC now preserves loop nest information. This optimization scrambles the loop nest beyond all repair. So we have to arrange to throw away and rebuild the loop nest structures, which might be controversial... Leading to... 2. Heuristics -- We really don't want to throw away the loop nest information unless we're going to see a big win. So ISTM we want to apply this optimization only when we're going to be able to eliminate a multi-way branch in the loop. I've got prototypes for #1 and #2 already done, the problem is getting them tested with real code. I've only seen this code trigger (thread across the backedge to a threadable multi-way branch) *once* during a bootstrap. I've manually verified the sample code from this PR, but that's far from thorough testing. 3. Relax the restriction for threading across backedges. So far I've just been hacking that test out of my sources when I want to look at the coremark testcase. That's obviously not sufficient. The good news is we can thoroughly any changes to allow more threading opportunities to be found across loop backedges.
