https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> --- Oh, and this is also another case where we end up with different out-of-SSA coalescing desires + outcomes. Sorted Coalesce list: -(16562, 0) t_6 <-> t_105 -(16562, 1) ivtmp.101_80 <-> ivtmp.101_81 -(16562, 2) jp_3 <-> jp_107 -(7908, 0) ivtmp.94_76 <-> ivtmp.94_174 -(1640, 0) ivtmp.107_29 <-> ivtmp.107_132 -(1640, 0) ivtmp.113_228 <-> ivtmp.113_229 ... +(3438, 0) ivtmp.74_16 <-> ivtmp.74_17 +(3438, 0) ivtmp.77_192 <-> ivtmp.77_226 +(3312, 0) ivtmp.67_95 <-> ivtmp.67_164 +(1716, 0) t_6 <-> t_105 +(1716, 1) ivtmp.101_80 <-> ivtmp.101_81 +(1716, 2) jp_3 <-> jp_107 +(1638, 0) ivtmp.87_104 <-> ivtmp.87_188 +(961, 0) jj_96 <-> _242 +(820, 0) ivtmp.94_76 <-> ivtmp.94_174 interestingly we have less coalesce fails with fold_build3_loc. Also edge frequencies seem to be very different in the end even though we predicted things the same... So I still think there's some underlying issue "elsewhere" (apart from nothing adjusting BB "order" while we still have a CFG around, making predicted edges fallthrus dependend on whether they are backwards or forward jumps).
